klsmithphd / aoc-clj Goto Github PK

Some thoughts on speeding things up:

• Might think about caching all the indices that have hashes with five characters. These are also valid three-character sequence candidates in and of themselves, but still need to look for the three-character hashes too
• Can maybe create a hash-lookup from the repeated character to the index/offset. Could probably still keep the windowed approach I currently have in place.
• Don't do the stretched hashing on strings, just do it on the bytes and then convert to strings at the end

Either there's a recurrence in the pattern so you don't need to simulate 400,000 rows, or there's a much faster implementation of figuring out the next row values (likely just using bit operations instead of the string checks I'm doing now.)

I think I had worked this out by hand back in the day.

https://github.com/Ken-2scientists/aoc-clj/blob/4a4c63381a3771a28bb1e6d4997f442e69290bb0/test/aoc_clj/2015/day04_test.clj#L11

The iterative approach to generating the fill string is probably the thing that's too slow, particularly the part that reverses the initial string.

An alternative implementation ought to be able to generate the entire string in one go (without iteration/recursion), which could avoid the intermediate creation of temp string sequences.

I'm marking the test as slow, but it might be worth just living with.

Places where this would be handy:

• 2016 Day 08
• 2019 Day 08
• 2019 Day 11
• 2021 Day 13
• 2022 Day 10

The description that accompanies part2 hints that you probably need to actually interpret the "assembunny" code and figure out what it's essentially doing or else the operations are going to take forever.

It says, "As you run the program with this new input, the prototype computer begins to overheat. You wonder what's taking so long, and whether the lack of any instruction more powerful than "add one" has anything to do with it. Don't bunnies usually multiply?"

Letting the program run, I did eventually get the correct solution, but it takes a long time.

Part 1 is slower than it needs to be, but it's at least usable. Part 2 takes far too long to run as-is

On my old mac's devcontainer, it took close to 35s to complete part 2.

When the game self-plays, timing issues can cause the "player" to lose sometimes.
Each run can result in a different outcome, whereas it ought to be possible for the solution to be
completely deterministic.