I finally use my AOC library from previous years for my Pos2 class. I’ve done AOC enough that I can write Pos2 and Pos3 and map/pathfinding without a lot of thought (which I think may be the point?), but there’s only so many times I’m willing to type it all out.
A Good Thing about Rust for AoC: the pathfinding crate, which has Dijkstra and A* but also BFS/DFS, Edmonds-Karp, Kruskal and Prim spanning tree, you get the idea.
AoC Day 5.
Ranges! Ranges! If I weren’t using a language which has a set of built-in range types, I’d have written one by now. Rust in particular has range-ext which, all right I don’t need it to do the range intersections, but it’s handy to have the library code to hand. Start, end, contains, empty, intersection…
Goodness, built-in ranges don’t implement Ord so I had to write my own sort_by function. Heh.
I have written my own Range.
Day 6 was a bit tricky. My partner gave me an all-important clue for part 2. Which I had not requested at that point. Or did I by telling him the problem? In the end I programmed part 2 twice to get to the pretty version (Major spoiler for part 2: by treating the whole input as a matrix that i transposed left thus getting 1 number per line).
Day 7 Part 1 was very straightforward. Part 2 as well … in my early morning considerations what might be part 2, one of my guesses proved right except for the story about it (I considered beam strength might be what we need to calculate, but he’s calling it many worlds… so what, same solution. And I would be done, if I had considered larger numbers)
edit: Day 7 Solution.
my big mistake besides the integer overflow was when modifying my example solution to work with bigger numbers, I threw away the working code and copied from part one and forgot that in the big if-ifelse-else construct I actually needed to do something in the else branch. Meh. I even wrote a comment inside the else.
edit 2: some of my friends struggled quite a bit today. But one person was able to code a solution that had the result for part 2 upon reading the last character of the input which is quite impressive but I know how they did it and if I had all the time, I would go and add that to my code as well as a second solution.
I think this is the first one this year where I haven’t started part 2 by copying my part 1 code. (Most solutions I see roll them into one, but I like having two separate programs, even if they overlap a lot.)
Having a transpose that comes out as
4
431
623 +
175
581
32 *
satisfies my sense of neatness.
I’ve seen some solutions that do this as exhaustive search with aggressive cacheing, but having a single rolling list (well, hashset in part 1, hashmap in part 2) to keep track of beam locations (and, in part 2, strengths) worked for me. This is one of the few AoC problems where I’ve done it line by lilne rather than slurping everything into a data structure then working on that.
Is it spanning tree? No, it’s connected components. But quite a lot of data mangling first so that I have the right things to feed to the connected_components function in pathfinding. And more in part 2 where it has to move inside the loop. I’m sure I could have got away without the clone() but while I was thinking about how to do that my inefficient code gave me the right answer.
Both 6 and 7 were relatively straightforward for me; they didn’t feel like “weekend” problems. 8 was rather tougher.
We talked about the search solution for day 7 among my friends and most of us agreed that the person who was trying it, was doing it … “wrong” aka needlessly expensive.
I agree. I rewrote my whole ugly solution to this after realizing I could do that.
For Day8 I am anticipating a Dijkstra thingy or something like it for part 2 and I have finally begun writing my own tupel class for n-dimensional coordinates because… I can. I have not yet worked on the actual problem except for input parsing (well and having programmed both distance and manhattan distance for my tupels) … because work.
Day 8 two kinds of people:
those who do the square root and those who don’t bother.
Day 8 also two kinds of people:
those who do connected components / Kruskal / other spanning tree type stuff, and those who don’t.
I still haven’d had time to really do anything. Adulting > AoC sadly.
Finally done with Day 8.
Treemaps are really cool and so fast… thanks Java! That did all the heavy lifting on this one for me.
Tupel was very useful.
My tupel can do distances. N-dimensional. But manhattan would not have worked I think?
In any case I made another stupid error in this bit after changing around the ifs to look better:
void findNetwork(TupelLong tupelA, TupelLong tupelB) {
... networkA = findNetwork(tupelA);
... networkB = findNetwork(tupelB);
if (networkA == null && networkB == null) {
//make a new network that contains a and b
} else if (networkB != null && networkA == null) {
//add a to network that contains b
} else if (networkA != null && networkB == null) {
//add b to network that contains a
} else { //both non null.
if (!networkA.equals(networkB)) { //merge the networks
} else {
//there is actually nothing to do A and B are in the same network
}
}
}
Quite a tricky one here, the sort of thing I’d traditionally expect as a weekend problem.
In fact I’d invented the technique I needed for an Everybody Codes problem this year, but it still took me a while to recognise that that was the case. Then I had to define the “inside”, which I tried with winding numbers but eventually worked up as a flood fill when finding the nature of edges was too hard.
I did part 1 during lunchbreak more or less. Then I saw part 2 and it reminded me we did a very similar problem 2 years ago or so with polygons? I have not looked at your solution yet. But I think it will be a tricksy one as well. But there is only 3 more days of problems after this, so the difficulty has to go up a bit to challenge us, right?
I hate it when I have to do this.
I had great fun with part 1. Using a BigInt as a bitfield and then doing a BFS with xor. Lovely stuff.
But then part 2 was clearly a linear algebra system. And not one susceptible to simple elimination (e.g. there’s a switch which only affects one field, so I can discount that, then there’s another switch which affects that field and one other, etc.); I wrote a simplifier, but even then a cartesian product was far too slow.
So basically I had to use a linear algebra library, and I don’t like doing this because I don’t know the algorithms well enough. I’ve written Dijkstra search, I understand Dijkstra search, I don’t need to do it again, so I’m happy to use the version in the pathfinding crate. But linear solving is far enough outside my maths headspace that it’s basically a matter of choosing a library, setting up the problem, and hoping for the best. (Then choosing a different library because the example code from the first one doesn’t work any more.)
Still, at least I didn’t have to invoke Z3, which is just a black box to me. With microlp at least I can vaguely work out what it’s doing.
I did this. And my algorithm is failing for some stupid reason.
I am reasonably sure I did the parsing right. Lots of unit testing for that.
I debugged the algorithm and somehow it never finds a result for several machines.
Found my mistake: I was made an initial mistake creating the button bitmasks and then I turned the order of bits around which fixed the missing “size” parameter but since i did not also invert the lights bitmask…
Re my comments yesterday: yeah, I’ve done path counting before, so I’ll hive that off to the library and concentrate on the data wrangling side of things.
There’s a thing I do that I haven’t seen in other code: treat a three-character string as a base-36 number, which will fit in a 16-bit unsigned int. Then I’m working with ints rather than strings (which can be particularly fiddly in Rust), and I’ll only convert back to the alphanumeric form if I need it for debugging.
There’s an interesting structure to my data, with one required node in cluster 2 and the other in cluster 5. (The standard path counter will fail if there are any loops, and in theory there could be loops in this problem that didn’t affect the outcome, but I took a chance.) Image from graphviz of course; I don’t tend to use it for solving these problems, but it’s great for showing what’s going on when I’m curious after the fact…
Which also shows that “you”, seen in part 1, is one of the nodes in the chokepoint before cluster 6, thus usefully reducing the size of the problem for the first part.
(All my code is at Firedrake/adventofcode2025: Advent of Code 2025 - Codeberg.org by the way.)
If the intended lesson here is that a good programmer should recognise when a problem is intractable and consider alternatives, I’m here for it. Still a bit iffy.
I tried using Gauss Elimination to solve the equation. Sadly i found out it only works on square matrices and there are a lot of cases where the number of buttons and the the joltages given do not add up to a square matrix or I am reading things wrong.
I am unwilling to just call a library. I spent hours trying to understand and implement this and it turns out… this was still the wrong approach.
My first attempt with BFS with just brute force ran into such a quick deadend that I am not going to try that again. I don’t really see how to optimize any kind of search on this. It must be solved with math. And I am not great at that. I was willing to learn … one approach. Admittedly I took the first one the chatbot suggested without further checking if it was the right approach to solve this.
I have made another tiny attempt on day 9 Part 2 which was equally greeted with failure. At least it was fast failure.
I had a shit week at work. The difficulty on AoC ramped up too quickly for me to keep up this year and while at first I was kind of "well okay only 12 puzzles should be fine… I kind of needed the slower curve in the difficulty it seems. I haven’t even tried Day 11 or Day 12 at all. I just don’t have the bandwidth no matter how much I enjoy coding normally.
I don’t have anymore time for coding left today. Maybe tomorrow or Sunday.
I had vaguely thought about dropping to one per two days, but it turned out they didn’t break my coding skill ceiling. I was fortunate.
I understand that. I don’t like to do it when it’s on the outside edge my skill set to write the code the hard way. But in this case I realised that (a) this is a standard sort of problem that there exist libraries to solve and (b) I’m not going to recreate decades of development in the field in the few hours I’m willing to give the problem.
i actually did try it. and i am still not getting the right results. and it really feels like a cheat.
but i am out of time for programming for today i think.
I am a bit sad I wanted to really get to do yesterday part 1. looks like a neat programming thing. even today which looks like exponential sokoban seems more tempting than solving linear equations.
I, too, am hesitant to use a 3rd party library unless either:
