Advent of Code 2024 - Historian goes looking for history in all the wrong places
Advent of Code 2024
copy pasting the rules from last year's thread:
Rules: no spoilers.
The other rules are made up aswe go along.
Share code by link to a forge, home page, pastebin (Eric Wastl has one here) or code section in a comment.
It's that time of the year again. Last year was tough for me, i got laid off in the middle of dec and it kinda killed the vibe. I'll see how long I keep up this year. My historical backlog is growing but I've made peace with it.
Day 3
Got stuck forever on 2-2 because of an edge case that only showed up in 7/1000 reports, ended up just brute forcing it, just ran the fitness function after removing one element at a time sequentially.
Then solved 3.x in like minutes because I could be worse at regex, posting code mostly because no-one else posted F# yet.
edited to fix spoiler header formatting
Day 8
Al lot of grid index shuffling these past few days! Not too difficult yet though, will this year be gentler or much harsher later?
tl;dr: Day 5 was most perfectly fine code thrown out for me, because I ran face first into eliminating imaginary edge cases instead of starting out simple.
OK nerds, I was coerced into doing day five so I'm posting it here.
relevant to this sub's interest is this Reddit thread about "LLM cheaters" in AoC:
https://old.reddit.com/r/adventofcode/comments/1h9cub8/discussion_on_llm_cheaters/
d8: done, and nothing to say about it.
I almost got done in by floating point arithmetic, I think
Day 3 well suited to JQ
For 3: I made dart one-liners for both. Pasting the juicy parts.
Advent of Code is one of these things I wanna do every year and then I end up in fucking end-of-the-year crunch time every December and work for 10-12 hours and really don't wanna code after work anymore.
But hey, here's a quick solution for day 1. Let's see how far I make it.
Yay, day 3 with Regexp magic.
My part 2 solution didn't work with the real input but worked with all the test cases I threw at it, so I couldn't figure out what was wrong with it and I'm too lazy to debug any more right now.
I will probably slow down and try to solve the problems on the weekends rather than daily. Anyway, 9:
I would do day 3 today except
Maybe this weekend or if I can't sleep again or if I get especially bored at work.
4:
Day 7 ::: spoiler 1 and 2 On reflection, it was a pretty fun little problem to solve. There wasn't much of a difference between the two parts. I ran into some bugs with my recursion termination conditions, but I got them in the end.
Part 1. A quick look at the data showed that the input length was short enough to perform an O(2n) search with some early exits. I coded it as a dfs.
Part 2. Adding concatenation just changes the base from 2 to 3, which, while strictly slower, wasn't much slower for this input. :::
Ah thanks for reminding me that time progresses and that it is now December.
I have done 1.1 through 2.2 and have nothing interesting to say about them.
Day 9 seemed pretty straightforward, don't really have anything to add.
I had a lot of trouble because my input was truncated, despite the site warning me about that. Did I listen? I did not.
edit
days 5 and 6.
5: ::: spoiler p1, p2: Initially, I was thrown for a loop. It wasn't apparent to me what data structure to use or the problem's properties. My first (and correct) instinct was to interpret the data as a directed graph, but then what? Try to find some total ordering, if such a thing was possible?
As it turns out, that instinct was also correct. By drawing the sample data (or counting or printing it out), I noticed that every page number had a defined relation with every other page number. This meant that a total ordering (rather than a lattice) existed, meaning it was possible to construct a comparison function.
So, the algorithm for part 1 was to check if a list was sorted, and part 2 was to sort the list. There's probably a 1-3 line solution for both parts a and b, but that's for Mr. The Reader. :::
6: ::: spoiler p1, p2 as discussed in a different part of the thread, I consider the input size for square inputs to be N, the "side length" of the square.
Context: I participated (and completed!) in AoC last year and pragmatically wrote my code as a set of utility modules for solving these pathological problems. So, I had about 80% of the boilerplate for this problem written, waiting for me to read and relearn.
Anyway, the analysis: P1. was pretty straightforward. Just walk along the map, turn right if you hit an obstacle, and stop when you leave the map. I guessed that there may be a case where one needs to turn in place more than once to escape an obstacle, but I never checked if that was true. Either way, I got the answer out. This is a worst-case O(n2) solution, which was fast for n = 130.
P2. I chose to brute force this, and it was fine. I iterated through the grid, placing a wall if possible, and checked if this produced a loop using an explored set. This is worst case O(n4), which, for n=130, takes a few seconds to spit out the answer. It's parallelisable, though, so there's that. If a faster solution existed, I'd love to know. :::
day 6
code for day 5, written in dart to be short:
I can't sleep, so here's 1-1 and 1-2, unfortunately I couldn't think of any silly solutions this time, so it's straightforward instead:
2-1: I have quickly run out of hecks to give. This is the sort of problem that gives prolog programmers feelings of smug superiority.
As usual the second part has punished me for my cowboy code, so I'll have to take a different more annoying tack (maybe tomorrow). Or you know I could just double down on the haphazard approach...
I decided to double down on 2-2, since bad code is one of life's little pleasures. Where we're going we won't need big-oh notation