cacheson

cacheson, 5 months ago

Looks like this fix for nimsuggest didn't make it in though, so I'm still on devel for now.

cacheson, 5 months ago

Nim

I'm caught up!

This one was pretty straighforward. Iterate through the beam path, recursively creating new beams when you hit splitters. The only gotcha is that you need a way to detect infinite loops that can be created by splitters. I opted to record energized non-special tiles as - or |, depending on which way the beam was traveling, and then abort any path that retreads those tiles in the same way. I meant to also use + for where the beams cross, but I forgot and it turned out not to be necessary.

Part 2 was pretty trivial once the code for part 1 was written.

• Day 16, part 1
• Day 16, part 2

cacheson, 5 months ago

Nim

Almost caught up. Not much to say about this one. Part 1 was a freebie. Part 2 had a convoluted description, but was still pretty easy.

• Day 15, part 1
• Day 15, part 2

cacheson, 5 months ago

Huh, I wasn't expecting more Gundam Seed after almost 20 years. MyAnimeList link for English speakers.

cacheson, 5 months ago

Nim

Getting caught up slowly after spending way too long on day 12. I'll be busy this weekend though, so I'll probably fall further behind.

Part 2 looked daunting at first, as I knew brute-forcing 1 billion iterations wouldn't be practical. I did some premature optimization anyway, pre-calculating north/south and east/west runs in which the round rocks would be able to travel.

At first I figured maybe the rocks would eventually reach a stable configuration, so I added a check to detect if the current iteration matches the previous one. It never triggered, so I dumped some of the grid states and it became obvious that there was a cycle occurring. I probably should have guessed this in advance. The spin cycle is effectively a pseudorandom number generator, and all PRNGs eventually cycle. Good PRNGs have a very long cycle length, but this one isn't very good.

I added a hash table, mapping the state of each iteration to the next one. Once a value is added that already exists in the table as a key, there's a complete cycle. At that point it's just a matter of walking the cycle to determine it's length, and calculating from there.

• Day 14, part 1
• Day 14, part 2

cacheson, 5 months ago

Nim

This one was a nice change of pace after the disaster of day 12. For part 1 I kept a list of valid column indexes, and checked those columns in each row for reflections, eliminating columns from the list as I went. To find vertical reflections, I just transposed the grid first.

Part 2 looked daunting at first, but I just needed to add a smudges counter to each column candidate, eliminating them when their counter reaches 2. For scoring, just count the 1-smudge columns.

• Day 13, part 1
• Day 13, part 2

cacheson, 5 months ago

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

cacheson, 5 months ago

And finally:

• Day 12, part 2 rewrite 3 😑

cacheson, 5 months ago

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

cacheson, 5 months ago

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

Link for the lazy

cacheson, 5 months ago

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

cacheson, 5 months ago

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

cacheson, 5 months ago

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

cacheson, 5 months ago

I'm able to appendix carry a 4" Springfield XD mod2 without too much trouble. The 1911 seems to have roughly the same dimensions, though maybe a longer barrel depending on which specific one you have. Since I started carrying I've switched to wearing slightly larger shirts than before, so that they don't print and ride up as much. I guess my main concern with carrying a 1911 would be the weight of it, but that's more a comfort thing than concealability.

Practice is obviously good, but the smaller guns are going to be inherently less accurate than the larger ones. The Ruger might be a good compromise, if you're not looking to make any further purchases. If you are, then the Sig P365X and Springfield Hellcat, both with red dot sights, might be worth looking into. The RDS makes sight radius no longer a concern, so it narrows the gap between smaller and larger guns.

cacheson, 5 months ago

Though also if you plan to appendix carry, it would be good to look into how safe the 1911 is for that. Since it's an older design, there may be additional concerns about having it pointed at your femoral artery.

cacheson, 5 months ago

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

cacheson, 5 months ago

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

cacheson, 5 months ago

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

cacheson, 5 months ago

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

cacheson, 5 months ago

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.