This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (35)
- # beginners (137)
- # braveandtrue (1)
- # calva (33)
- # cider (40)
- # cljsrn (4)
- # clojure (10)
- # clojure-spec (26)
- # clojure-uk (29)
- # clojurescript (18)
- # core-async (6)
- # cursive (1)
- # emacs (2)
- # figwheel-main (17)
- # fulcro (28)
- # jobs-discuss (4)
- # leiningen (1)
- # lumo (19)
- # off-topic (2)
- # om-next (1)
- # reitit (2)
- # rum (8)
- # spacemacs (19)
- # tools-deps (9)
- # yada (3)
I'm gonna have to finish part two tomorrow; I don't think I can rely on creating a static graph with JGraphT, I need to be able to expand it on the fly. 😞
Things I re-learned today: it’s really hard to memoize a recursive anonymous function….
@potetm - I’m still working on comparing my failed attempt at 4 with your solution - in looking back through the thread here I noticed you highlighted a discussion in #10 so I plan to jump around and go to #10— keep highlighting good ones or ones that follow others — I am at the level where I can get started but usually end up stuck with most of the problems and I need the video to get through
djikstra (weighted BFS) works but is kind of slow. You may need to cheat the dimensions or use A*,
I my new holiday spirit of of writing garbage code for AoC I did the the former, but I may switch over after I clean up and commit because it’s an interesting search problem
there's probably alot of potential to optimize, but it runs in about 2,5 secs for part 2
And it looks like your effective X search is larger than mine too… It looks like the main difference is I visit one node at a time and you visit all the nodes for time T at the same time, which seems to provide some efficiencies
right I'm just storing which nodes are reachable after n seconds, advancing the seconds until the target is in this set.
I'm not sure whether I have an off by one error, or my solution is 'better' than the approved one. The example runs correct, but on my data the output is 1088, while the accepted answer was 1089.
Probably a bug then. When I filter the routes more aggressively I do get the answer, and it's a solution that takes less steps.
@drowsy used your approach of sets 1 distance at a time, after I wasted half a day waiting "per-xy" to complete, with all the different filters and sorting and stacks/lists/queues combinations.
From a Kotlin slack channel came the awnser, apparently when you change the tool, it has to be valid in the current one. So for example you can't put away the torch in a rocky place to move into a wet place. Or put your rock climbing gear in a narrow area to move to a rocky one.