I did part 2 manually! I will not bother writing a code solution unless I feel like it.
well well well
AoC, so you thought you could dredge up my trauma as an EE grad by making me debug a full-adder logic circuit? How dare you. You succeeded.
I did part 2 manually! I will not bother writing a code solution unless I feel like it.
well well well
AoC, so you thought you could dredge up my trauma as an EE grad by making me debug a full-adder logic circuit? How dare you. You succeeded.
thanks
I've probably learned that term at some point, so thanks for naming it. That made me realise my algorithm was too thicc and could just be greedy.
22
uh
pretty straightforward. At least it's not a grid!
21!
Finally managed to beat this one into submission.
P1
I created this disgusting mess of a recursive search that happened to work. This problem was really hard to think about due to the levels of indirection. It was also hard because of a bug I introduced into my code that would have been easy to debug with more print statements, but hubris.
P2
Recursive solution from P1 was too slow, once I was at 7 robots it was taking minutes to run the code. It didn't take long to realise that you don't really care about where the robots other than the keypad robot and the one controlling the keypad robot are since the boundary of each state needs all the previous robots to be on the A button. So with memoisation, you can calculate all the shortest paths for a given robot to each of the directional inputs in constant time, so O(kn) all up where n is the number of robots (25) and k is the complexity of searching for a path over 5 or 11 nodes.
What helped was looking at the penultimate robot's button choices when moving the keypad robot. After the first one or two levels, the transitions settle into the table in the appendix. I will not explain the code.
appendix
(P(0, 1), P(0, 1)): [],
(P(0, 1), P(0, 2)): [btn.r],
(P(0, 1), P(1, 0)): [btn.d, btn.l],
(P(0, 1), P(1, 1)): [btn.d],
(P(0, 1), P(1, 2)): [btn.d, btn.r],
(P(0, 2), P(0, 1)): [btn.l],
(P(0, 2), P(0, 2)): [],
(P(0, 2), P(1, 0)): [btn.d, btn.l, btn.l],
(P(0, 2), P(1, 1)): [btn.l, btn.d],
(P(0, 2), P(1, 2)): [btn.d],
(P(1, 0), P(0, 1)): [btn.r, btn.u],
(P(1, 0), P(0, 2)): [btn.r, btn.r, btn.u],
(P(1, 0), P(1, 0)): [],
(P(1, 0), P(1, 1)): [btn.r],
(P(1, 0), P(1, 2)): [btn.r, btn.r],
(P(1, 1), P(0, 1)): [btn.u],
(P(1, 1), P(0, 2)): [btn.u, btn.r],
(P(1, 1), P(1, 0)): [btn.l],
(P(1, 1), P(1, 1)): [],
(P(1, 1), P(1, 2)): [btn.r],
(P(1, 2), P(0, 1)): [btn.l, btn.u],
(P(1, 2), P(0, 2)): [btn.u],
(P(1, 2), P(1, 0)): [btn.l, btn.l],
(P(1, 2), P(1, 1)): [btn.l],
(P(1, 2), P(1, 2)): [],
21 (wip)
2 meme 2 memeious
Understandable, have a nice day
ok disco
It took me too long to read the prompt and see that without the shortcuts, it's a single path. I wasted too much time on search algorithms.
P1: Here's what I did: Walk the path. Every time you hit a new grid, check if the two shortcuts you can take will save you 100 ps.
To calculate the shortcut saving:
If you index every grid position on the main path from 0, then it takes X ps to reach position X, The time it takes to travel from start to X, then a shortcut to Y, then from Y to the end, is X + 1 + (main path length - Y). The time saved is then just Y - X - 1, modulo maybe like 5 fence post errors.
P2. The prompt wasn't really clear about whether or not cheating meant you can only travel through one set of walls before your cheat ends, or if it meant you could just move through walls for 20ps to wherever you could reach. Turns out, it's the latter.
The above formula is then a special case of Y - X - manhattan distance(X, Y).
20: currently a WIP but:
meme
Wait, so it’s all grids?
🧑🏿🚀🔫🧑🏿🚀
NBC/the media really killing it with painting him as a self-radicalised spook.
A wallpaper app? What is this, 2008?
LLMs, and everyone who uses them to process information:
25!
p1 tips
O(mn)/O(n^2^) is fast enough.50 stars baby!
https://imgur.com/a/hwEVy9H