Initial commit

2024/16/README.md

@@ -0,0 +1,23 @@
+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