Wanted to read it but all I get is a
NGINX 502 Error :/

Did you have prior experience with C++ before deciding to use it for the Advent? =)

Why are some points going blue? Are those part 2 obstacle locations? The animation makes me think there is some trick to finding them that I'm not aware of)).

One other thing I tried before was to represent a sequence of changes as a single large number (like 4 digits in base 19 because there are 19 possible changes in -9..9)
Then the 5d array can be a 2d array, where the other dimension is 19**4. But timings were about the same as 5d approach.

I just tried line profiling and indeed the last line with `sequences.clip().sum().max()` takes 50% of total part2 time. I tried putting the buyers dimension last - no change in performance.
It's just a heavy operation however you slice it I think =).

I was wrong here, numpy is also very good for day20 (Race Condition). If distances from starting point are a 2d numpy array then for every cheating offset you can get the gains for the whole grid at once. My solution time went from 1.7s to 100ms when I switched to this approach.

I thought light grey was a background color, was pretty puzzled how the dark grey stuff could mean locks 😅. Almost asked you about that))

Fast solutions aren't general, they use some properties of the input that aren't in the task description. I studied the input program's flow on paper to figure out a shortcut for part 2. A direct "black box" approach does take forever.

I want to debug that circuit with real wires 😄

Pretty proud of solution times this year - all days run in just ~2.5s.
Day 20 Race Condition used to take almost 2s before I gave it some numpy love.

#python solutions and animations code here: github.com/gereleth/aoc...

They are clumped together rather nicely!

Well to be honest this is the first time I've imported numpy in this year's advent :)

I made a couple of manual adjustments to avoid white edges intersecting).
And 0.5px stroke weight is great for hiding the outer hairyness.
I couldn't untangle the crowded third layer, some connections through the center are unavoidable.

I was randomly throwing networkx layouts at the problem, and spectral clustering split nodes into sort of growing layers:
..
|\
....
|\\\\
.......
Where the max clique was the tight group on top. So I made these concentric circles going in bfs layers from max clique.

I had a similar solution at first, only I had a dict with total sequence profits and a separate "seen" set that I reset between buyers. Ran in ~6s.

Then I switched to a 5d numpy array for sequence results and worked on buyers in a vectorized way. Takes ~0.7s now. github.com/gereleth/aoc...

Isn't Manhattan distance just abs(xa-xb) + abs(ya-yb)? Why walk the path at all to find it?
Or maybe your data is stored differently, linked list style...
I have points as tuples (y,x) so Md calculation is just arithmetic and so is the diamond loop.

I'm talking about this difference:

for every node in path after a:
is it close enough?
is the gain good?
=> median ~5000 iterations for various `a`s

vs

for every node within 20 manhattan of a:
is it in the path?
is the gain good?
=> ~400 iterations for every `a`