cacheson

And finally:

• Day 12, part 2 rewrite 3 😑

Nim

I don't want to talk about it. -_-

• Day 12, part 1
• Day 12, part 2
• Day 12, part 2 rewrite 1
• Day 12, part 2 rewrite 2

Nim

Approached part 1 in the expected way, by expanding the grid. For part 2, I left the grid alone and just adjusted the galaxy location vectors based on how many empty rows and columns there were above and to the left of them. I divided my final totals by 2 instead of bothering with any fancy combinatoric iterators.

• Day 11, part 1
• Day 11, part 2

Unfortunately then it'll be broken for kbin users. I can do it anyway though if the bot is too annoying, just lmk.

Nim

I got a late start on part 1, and then had to sleep on part 2. Just finished everything up with a little time to spare before day 11.

Part 2 probably would have been easier if I knew more about image processing, but I managed:

• Made a copy of the grid and filled it with . tiles
• Copied all of the path tiles that I had calculated in part 1
• Flood-filled all the . tiles that are connected to the outside edges of the grid with O tiles
• Walked along the path, looking for an adjacent O tile at each step. Stopped when one was found, and recorded whether it was to the left or right of the path.
• Walked the path again, flood-filling any adjacent inside . tiles with I, and counted them

Code:

• Day 10, part 1
• Day 10, part 2

I love these memes that turn into threads full of vim tips. You really can do anything within vim. You can even exit vim!: !killall vim

Huh, I'm going to have to try that at some point. It's even got nim support.

Link for the lazy

Nim

Pretty easy one today. Made a Pyramid type to hold the values and their layers of diffs, and an extend function to predict the next value. For part 2 I just had to make an extendLeft version of it that inserts and subtracts instead of appending and adding.

• Day 9, part 1
• Day 9, part 2

Nim

I like how if you have an error in your calculations, you end up wandering the haunted desert for eternity. Very flavorful.

My solution for part 2 is pretty much the same as for part 1, just modified to work on a sequence of nodes instead of a single node. However, it doesn't find an answer in the time that I was willing to wait for it. I thought about trying to optimize it to run faster, but figured that if it was taking this long on Nim, then interpreted languages would have no chance, so that couldn't be the right approach.

I suspected that maybe the ghosts arrived at the Z locations at predictable intervals. I added some code to output the step count each time each ghost reached a Z (see commented code), and my suspicion was correct. Just needed to calculate the least common multiple of the 6 cycle lengths.

• Day 8, part 1
• Day 8, part 2 partial solution
• Day 8, part 2 actual answer

Nim

I wrote some nice code for sorting poker hands, just defining the < and == operations for my CardSet and Hand types, and letting the standard library's sort function handle the rest.

It was quite frustrating to be told that my answer was wrong, though. I dumped the full sorted hand list and checked it manually to make sure everything was working properly, and it was. Wasted a few hours trying to figure out what was wrong. Ended up grabbing someone else's code and running it in order to compare the resulting hand list. Theirs was clearly ordered wrong, but somehow ended up with the correct answer?

Turns out that Camel Cards isn't Poker. -_-

Rather than rewrite my code entirely, I settled on some slightly ugly hacks to make it work for Camel Cards, and to handle the wildcards in part 2.

• Day 7, part 1
• Day 7, part 1 second attempt
• Day 7, part 2

Nim

Hey, waitaminute, this isn't a programming puzzle. This is algebra homework!

Part 2 only required a trivial change to the parsing, the rest of the code still worked. I kept the data as singleton arrays to keep it compatible.

• Day 6, part 1
• Day 6, part 2

Yeah, roughly the same idea. I guess I could have just used HSlice for my range type, I thought maybe there was some special magic to it.

It looks like your if-else ladder misses a corner case, where one range only intersects with the first or last element of the other. Switching to <= and >= for those should take care of it though.