Unfortunately, more matrix walks. Part 2 is a simple extension of part 1 (hypothesize a turn and walk until you reach the current position or not), and I can’t be bothered to complete it, I’m afraid.
Decided to get some sleep last night rather than do the puzzle when it dropped.
I copied some of my code from day 4, so I didn’t have to worry about parsing again. In part 2 I just count steps until I hit a wall or exceed the number of tiles.
For part 2 I figured that the guard loops if and only if he ends up going through the same location, in the same direction, more than once. So, whereas in part 1 I tracked only the locations, in part 2 I tracked the locations with the direction the guard was walking when he passed through them. Worked like a charm… but took longer than I expected 
, so much so that I interrupted the execution and added a printout to see where it was hanging. It didn’t; it just took a while.
Glancing over the solutions posted in the Reddit thread, it turns out that you can get a solid speedup by testing only the positions the guard walks before you place an obstacle. I tried it and my execution time improved as follows (seconds, naturally):
| debug mode | release mode | |
|---|---|---|
| checking all positions | 62 | 37 |
| checking positions on unobstructed path | 12 | 7 |
It’s worth looking at the Reddit solutions for insights like this. Also to wonder at some applicants’ apparent penchant for self-harm use of other languages. I’ve seen the following languages used, ordered by what I consider increasing insanity foolhardiness stamina:
- Excel or Google Sheets
- variants of APL
- x86_64 assembly
- Vim keystrokes
- variants of C / C++
2 Likes
Another idea is to count the visits of each cell. After 4 you know that you went at least twice from the same direction into a certain cell.
1 Like