24 lines
1.8 KiB
Markdown
24 lines
1.8 KiB
Markdown
|
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
|