advent-of-code/2024/16

Oh boy. My first time in a while doing something with mazes. I decided to go with a filling thing. I realized I need to put the direction as a dimension in the table of visited scores. So basically it would go up to the very last tile, and then be like "op, what if I went back to the start?", although I did not know that at the time. I did exhaust Python call stack, so I increased it, again and again. But I thought that surely, even with this dumb of an algorithm it should be able to do, so I decided to look for a bug. I used the depth variable (initally only used to indent print statements) as my own call stack limit that would still print the maze. I realized that even at 1000 depth, the maze was already filled, which puzzled me. I submitted the answer... and it was correct x)

For part 2 I first implemented something that would print only one best path. Then I realized my mistake, and then did something that would work if not for the fact that I optimized out 2 paths arriving with the same score. A <= changed to < later and it was fixed. The optimisation didn't cost much, the "allocating a list every recursion", very much so.

Since it was taking a long time to compute I realized maybe I could do something clever with only considering crossways, since there's quite a lot of corridors. But I decided to instead firsrt code two2.py, which would add the position to the set of best places only when the recursion hit the best score, which was hardcoded from part 1 (it took 48s to run alone, sooo). I tried it on demo, got None as answer to part 1 and 0 as answer to part 2, completly overlooked that, and let it cook on the real input. In the end, the first iteration of two.py ended up being cooked first, 11 minutes after, with the right answer.

...a win is a win I guess