advent-of-code VS advent_of_code

I was doing the AOC in Clojure, and decided to practice writing macros and used one in my solution.

Clojure

Luckily my part 1 solution was similar enough that I didn't need to change a lot to generalize it for part 2. Of course, I did start off by actually adding rows and columns to the image, so that approach had to change. But the way I counted galaxies was the same, so it was a pretty easy thing to amend.

Whew, this one was for sure the trickiest so far. Couldn't quite figure out what to google to find the right mathy stuff, so in the end I went with a hackier solution. It's for sure not pretty and a lot of copied code between the parts, but it works. Essentially I replace all non-loop tiles with a ., then I walk through the loop again always looking to the left and to the right. One of those will be inside, one will be outside. I figure out which is which, then I do a flood fill (bfs) on all the inside nodes to find everything.

I resisted the urge to do this in some clever numpy way. But this really felt like a problem meant for vectorized diff functions. Or for some neat recursive solution. I just went for something pretty straightforward and part 2 was not so nasty today :)

Started off by just trying brute force for part 2. But I figured it would not go so well, given the emphasis on "significantly more steps". So I went back and verified, and all of the paths are actually cycles :)

Solution here. I really wanted to make a common score function for part 1 and part 2, but in the end decided it's not worth the extra energy to figure it out in a clean way so I did it because my brain couldn't shut up about it. I still like my approach, where I just generate a score string for each hand, and then sort the input list with it.

Very fun day. Right now just iterating over speeds (but prettily, with one-liner list comprehension stuff). Thinking about the math, this sounds like solving two quadratic equations. Which I might try later :)

I don't merge ranges, but mapping a range takes roughly the same time for me as mapping a number. I just check if the input range is completely inside, otherwise i split it. So it's in the same order of magnitude as problem 1. Check out my solution, I feel I'm not explaining it well. Code is ugly but maybe clear enough.

I was quite surprised to see so many struggling with this. But I think that's because I didn't run in to problems with the tricky edge cases with my solution, so I never thought of them.