Advent-of-Code VS advent-of-code-wim

My DFS searches for a path by finding all the adjacent tiles and adding them to a stack. Then it moves to the tile on the stack and repeats this process either, till it finds the end or it runs out of new tiles on the stack. If it has found the end or a dead end, it reverts the steps up to a point, where another path is possible. That means, it gets in every little corner, before it finally finds the endpoint. The BFS might be so slow, because basically every new possible tile gets added to one big list that gets searched for every new possible tile. This naturally gets very big, berry fast, but is don't know any way to remove the tiles in this list that are not needed for comparisons anymore... Here is a Link to the code of the algorithms: Github

Here is my code: Github

here is a link to the original code on Github

Thanks for the extra example. I've added it to my CI and test suite in https://github.com/wimglenn/advent-of-code-wim/pull/89

Full code here

I'm using Python so I'll never be as fast as the people using Rust or C, but am still able to solve most puzzles in under 1 second (repo: https://github.com/wimglenn/advent-of-code-wim).

Thanks for the kind words, well the source is here so you can just take a look. You have to run with var AOC_DEBUG=1 in env to enable the rendering.

I used an AStar pathfinder already prepared from earlier years (aoc2022/q12.py), just leaving the default null heuristic. If I understand correctly that is just a BFS.

https://github.com/wimglenn/advent-of-code-wim/blob/main/aoc_wim/ocr.py has nearly all the letters we've seen (including a larger font used once in 2018) although it is missing the 5-wide Y that was in my 2016-day 08 puzzle

By the way, I found that if you're willing to use pathlib and a guard, you actually only need 2 of those 6 case statements - it looks like this.

Python (repo). I was particularly pleased with how quick the parsing was.

Python + "AOCR" + complex numbers.

Python