Fork me on GitHub
<
2018-12-22
>
tbrooke01:12:38

@potetm — Have the old videos scrolled off of Twitch? — I’m still back on day 4

potetm01:12:05

@tbrooke They have. I have the recordings I’m planning on posting on my site soon.

norman06:12:42

How I spent the last hour of my life:

norman06:12:43

target: 14,796

😱 4
norman06:12:08

Oh, my region is 14796 x 14796…. That’s kind of big ….

norman06:12:56

14x796 is much more manageable

fellshard07:12:28

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. 😞

norman08:12:48

Things I re-learned today: it’s really hard to memoize a recursive anonymous function….

uneman12:12:45

Is day22 pt2... A* again?! 😨

ihabunek12:12:39

seems so, but the map changes based on tool used

misha13:12:14

wasted hours, and solution passing tests returns wrong result after 20 minutes

misha13:12:01

reddit says dijkstra

tbrooke13:12:02

@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

norman15:12:54

djikstra (weighted BFS) works but is kind of slow. You may need to cheat the dimensions or use A*,

norman15:12:40

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

norman15:12:01

I do like the twist of the tools here. I kind of makes a 2d grid into a 3d grid

drowsy15:12:24

and representing it as a 3d grid actually makes the solution pretty straight forward.

drowsy15:12:26

there's probably alot of potential to optimize, but it runs in about 2,5 secs for part 2

norman16:12:29

You beat me: “Elapsed time: 5045.311258 msecs”

norman17:12:24

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

drowsy17:12:38

right I'm just storing which nodes are reachable after n seconds, advancing the seconds until the target is in this set.

gklijs17:12:58

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.

norman18:12:30

Maybe you are really good at changing tools 🙂

norman18:12:28

Are you allowing your search to go beyond the target [x y]?

misha18:12:33

it would return longer path then, not shorter. I also got shorter results

gklijs18:12:40

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.

misha20:12:49

@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.

misha20:12:54

and it doe not accept an answer

misha20:12:20

it is off by 4! can't even blame off-by-1™

gklijs20:12:08

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.

misha20:12:58

hm, looking into it

misha21:12:43

yep, that did it