I'm not posting code for day 23, as part a was a rather simple modification of code from an earlier day, and part b boiled down to staring at the input until figured out what it was meant to do, then writing a short program to do it much faster.

Day 24 ended up being a rather unenlightening brute-force. The first implementation I made (yesterday) either had a bug or horrible memory inefficiencies, which is why it happened now.

Day 25 ended up being pretty much writing out the definition of a Turing Machine and filling in the blanks per the input.

And so the challenge came to a close for me.

Was fun.

- Tomash

... back when you posted it at first. I didn't intend to do it, but figured I might have a think about it.

Yeah... I couldn't even understand the question. ^_^ That sort of programming is far beyond me.

So yes, I am very impressed.

hS

The code is here and I happen to like it. It's a nice implementation of the exercise with not much in the way of nasty hacks (the grid is sparse because of course it is, and I used C = R^2, but that's notational convenience)

- Tomash

The code

Now, the neat thing here is that you can apply the flips and rotations to the input rules instead of the grid windows. This means you only have to screw around with the entirety of the permutation group on the square once.

The bad news is that, for the hashmaps to behave, extracting out the grid windows is still annoying and looks ugly, as does putting the result where it should be.

But that could be a flaw of using [bool; N^2] for windows instead of [[bool; N]; N].
But I've been raised on the former representation, so oh well.

- Tomash

Firstly, this link heads to the code.

Now, in reference to the title, "loop until the answer stays the same for a while" is a valid technique in nemerical simulation code ... which this is. However, usually it would help to have some assurance that the system won't do arbitrary weird stuff a few more iterations after you stop looking, and that it'll actually settle down eventually. That is, you'd like to be convinced of stability.

However however,
a) The contest organizers assured us the procedure would be stable.
b) In practice, everyone just rolls with it except where the book said you need to watch out for stability issues.

- Tomash

So, first, the code.

Now, the confession. I'm not sure what I was thinking when I made the code first take a step and then check the conditions for the step after that. The two parts of step() should've been in the opposite of the order they're in.

But oh well. It works.

- Tomash

So, they said the instructions could be arbitrarily interleaved ... what better solution to that than good old-fashioned hardware threads! (Who am I kidding, there's probably better solutions.)

So, without further ado, a program made of gloriously overcomplicating things (or just implementing the spec exactly as written)

Also, the inputs are evil. Registers need to be 64-bits wide or things won't work.

- Tomash

I still haven't finished day 16, but day 17 was easy!

I took the incredibly naive approach in Lisp. Worked pretty well. It took a minute or two to run, though, and I exhausted the heap and crashed my code on the first runthrough. I had to expand the heap, or it wouldn't work. Come on SBCL, I'm only consing up a 50 million element circular list! :-P

...And I mistakenly named my post "Day 19". https://pastebin.com/mvHvquN5

The solution.

I do have to admit to cheating slightly here. My original, much more naive solution was running (and running, and running), and so I wandered onto Reddit. On the advent of code subreddit, I saw an offhand mention of svaqvat n plpyr (I think it might have been in a title, not sure), which inspired the current, way faster, solution.

- Tomash

So, my code is in this pastebin.

I'm liking that I figured out a way to unify parts A and B, and maybe a bit too unreasonably proud of that one bit where I cast a boolean to an int.

Concrit is appreciated, if anyone has any.

- Tomash

My solution for today was written in Common Lisp. Because Lisp, yey. I've done most of my solutions in either CL or AWK thus far.

It comes in two parts. The first is a slight refactoring of my day 10 solution into something actually callable (and having it return a giant bitvector!), in the file knothash.lisp: https://pastebin.com/j7xYL0ZF

The second part is the actual solution. Yes, I should have parameterized lengths, but I am lazy. The functions total-bits and colorize return the solutions: https://pastebin.com/T8Kh1iMW

is at this pastebin. It's in Rust, which is what I've been writing all of these in so far just to stay in shape with systems languages (given one of my possible research fields next semester).

It includes a copy-paste of my day 10 part b, code.

What I'm not the biggest fan of in my solution is that the region-find is rather inelegant and it feels like there should be something better than brute force there.

On the positive side, the program is rather clean, I'd say.

Anyone else have concrit? Solutions?

- Tmash