adventofcode 2022-12-24

nice! i think i don’t make enough assumptions about previously visited positions

The key point is we don’t care how we came in same position at a certain minute, so we can reduce the space by applying set.

but we do care, because the winds might be different?

they do repeat every lcm(width,height) steps, but besides that

i fixed my occupied function, now it all runs in 2s 😄

⚡ 1

i was caching whether a position is occupied it at a particular time. instead it makes a lot more sense to cache the position of all blizzards at a particular time, because it can be reused for all positions at that time

For a certain minute wind is always the same, so if we came at position [2 2] by 10 ways, we can go with only one [2 2].

yep, but the cache key has to be [(mod time cycle-length) position] not just position

of course in norman’s solution all times are considered in the same iteration, so I think we’re actually talking about the same thing

Yeah, I’m polishing my solution, but basically it’s similar to @norman ’s

and actually a priority queue isn’t need either, so switching to a regular queue made it even faster 🎉

Exactly, first I thought I need something like astar

mod1 seems like a useful function

👍🏻 1

more memoization gives "Elapsed time: 2843.663069 msecs" since wind-map loops every 600 steps

My answer for part 3 is 4666929 minutes. It’s just 77782 hours, or approximately 8 years of dodging blizzards. Without sleep of course.

Slowly wrapping up AoC before vacation is over. I didn’t remap all the blizzards each time step. Instead I used modulo arithmetic to check if any blizzards would be at a certain spot at a certain time. https://github.com/wevre/advent-of-code/blob/master/src/advent_of_code/2022/day_24_blizzards.clj

👏🏻 1

https://gitlab.com/maximoburrito/advent2022/-/blob/main/src/day24/main.clj I did my state management a bit differently than I normally do and ended up messing up the co-ordinates several times because of it. Probably at least a solid 30 minutes of extra debugging because of it.

Missed my alarm clock and overlept for 90mins 😭 Today’s solution is the slowest one in terms of runtime for me, it takes 5 minutes to run. I wonder if I’m missing something real obvious about pruning the search space. @norman how fast does your solution run? it seems like you’re storing a collection of winds for each round, whereas I’m just storing the original position and checking whether a position is occupied by adding time modulo (lcm width, height) , but it’s a linear search over the winds. I wonder if your way could actually be faster

hmm i could memoize the occupied function

well that cut the runtime down to 2mins 😅

day24.main> (time (part2 full-input))
"Elapsed time: 6188.766655 msecs"
859

👍 1