While reading the question I thought: “That’s not how Watts work”, but then this “answer” hit…

Cat by C418 is literally the only piece in the list I recognize.

I assume you’re referring to this. That was such a scary video.

This is not cool of Twitter.

That commonwealth is called the EU today and, along with NATO, is the reason why these countries are in a comparitively safer position. It would be much riskier for Russia to invade there.

I use Colemak where most punctuation is at the same place as in the US English layout, which programming languages seem to be optimized toward. For the layout I prefer ISO for the larger Enter key.

Rust

I simply check each starting position individually for Part 2, I don’t know if there are more clever solutions. Initially that approach ran in 180ms which is a lot more than any of the previous puzzles needed, so I tried if I could optimize it.

Initially I was using two hash sets, one for counting unique energized fields, and one for detecting cycles which also included the direction in the hash. Going from the default rust hasher to FxHash sped it up to 100ms. Seeing that, I thought that this point could be further improved upon, and ended up replacing both hash sets with boolean arrays, since their size is neatly bounded by the input field size. Now it runs in merely 30ms, meaning a 6x speedup just by getting rid of the hashing.

You can create an array filled with all the same values in Rust, but only if all values have the same memory representation because they will be copied. That just doesn’t work with Vec’s, because they must all have their own unique pointer. And to have uninitialized values at first (think NULL-pointers for every Vec) while creating each Vec, something like this is apparently needed.

The appropriate way would certainly have been to store the map as a Vec> instead of an array, but I just wanted to see if could.

Rust

Part 1 was super simple with wrapping_add and wrapping_mul on a u8. Building an actual hash map in Part 2 was nice.

Rust

The trick for part 2 is obviously to check when the pattern repeats itself and then jump ahead to 1000000000.

My code allocates an entire new grid for every tilt, some in-place procedure would probably be more efficient in terms of memory, but this seems good enough.

Rust

Part 2 turned out easier than I thought initially. My code assumes that there is only 1 mirror in each field which means I don’t have to remember where the smudge is, I just have to find a mirror line where the two halves differ at exactly one spot.

I don’t think there are many significant optimizations with regards to reducing the search tree. It took me long enough to get behind it, but the “solution” (not saying there aren’t other ways) to part 2 is to not calculate anything more than once. Instead put partial solutions in a dict indexed by the current state and use that cached value if you need it again.

It seems like you are actually constructing all rows with replaced ?. This won’t be viable for part 2, your memory usage will explode. I have a recursive function that calls itself twice whenever a ? is encountered, once assuming it’s a ., and once a #.

Rust

Took me way too long, but I’m happy with my solution now. I spent probably half an hour looking at my naive backtracking program churning away unsuccessfully before I thought of dynamic programming, meaning caching all intermediate results in a hashtable under their current state. The state is just the index into the spring array and the index into the range array, meaning there really can’t be too many different entries. Doing so worked very well, solving part 2 in 4ms.

Adding the caching required me to switch from a loop to a recursive function, which turned out way easier. Why did no one tell me to just go recursive from the start?

Rust:

Cannot move princess out of castle which is behind a shared reference

I have a sway workspace indicator on the left, the right side has:

• Monitor brightness
• Volume
• Local IP address
• CPU temperature
• Keyboard layout
• Local date and time
• UTC time
• Tray

If you’re on Arch, why don’t you just use the discord package from extra repositories and have discord simply update with pacman?

Sufficiency is just as important as efficiency, if not more so.