#adventofcode2025 — Public Fediverse posts

Day 12 done.

I really didn't like this one. Basically have to do some bounds checking "it obviously always works" or "it obviously will never work" on it to get it to work on the actual input, but it still NEVER FINISHES on the example. I'm slightly bothered that the problem is more or less unsolvable as written, but I'm really bothered by the actual solution for the input not working on the example. That's not a fun puzzle, that feels like I'm being tricked, like the puzzle was a prank on me. Leaves a real sour taste, especially being the last puzzle of this year's AoC.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day12 #Day12 #Rust #RustLang #Programming #CodingChallenges #AoC #AoC2025 #AoC2025Day12

Day 11 done.

Memoization actually worked for this one. My first instinct was to just crawl the graph with a memo, and it fortunately did the right thing. It was effectively an exhaustive depth-first search. Really not much to discuss.

My code is not nice or clean, but after yesterday's, I can't even be assed to clean it up or properly comment it. I barely gathered the gumption to pass errors up, and when I started writing it, I was just throwing unwrap() everywhere.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day11 #Day11 #Rust #RustLang #Programming #CodingChallenges

Today I "cheated" and used scipy's MILP solver for Part 2. Discretion is the better part of valor, as they say, and writing a constraint solver by hand is not what I had planned for this Wednesday morning. The existence of `uv` to deal with all the dependencies makes reaching for scipy for even little scripts like this an easy choice.

Part 1 was trivial. Treat the lights and the buttons as bitmasks and recognize that buttons XOR themselves so they're pressed at most 1 time each. Generate the smallest combination of buttons that XOR to the target.

Part 2 is probably solvable via something like DFS before the heat death of the universe, but it would take way too long. Instead, I used scipy's integer linear programming solver, defined the constraints, objective, and bounds, and let it do its thing.

https://github.com/biesnecker/aoc-anyhow/blob/main/202510.py

#adventofcode #adventofcode2025 #python #scipy

Day 9 done.

This one was really hard for me. Part 1 wasn't bad at all; I could basically use the entirety of what I did yesterday for it.

Part 2 was really hard. At first, I tried actually building a HashSet of all the red and green tiles, and then a HashSet of all the areas for each pair, and checking them against each other. Needless to say, that wouldn't work. Building the tile HashSet alone would have eaten up more memory than I have on my computer, and I should have realized that immediately looking at my answer to part 1 (which was an area of over 4 billion tiles). I thought that checking a line of green tiles through the area wouldn't necessarily work, because a malicious input could make that not work (two immediate right or left turns could make a pair of adjacent green tile lines that would still work), but it turns out that it works fine for my input. Probably all inputs.

It works. I don't feel totally satisfied with the solution, but it works.

I think a more robust solution could be to trace the outline and fill it with square area units, then for each area to test (ordered from largest to smallest), repeatedly cut area out of it with the green tile squares. If all overlapping areas are tested and there are still un-cut squares, the area is invalid; move on to the next. If the area is cut completely to nothing, then it is the best area. I'm not going to implement this, because it sounds like a total fiddly pain, but I would be interested in seeing somebody else's solution along these lines.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day9 #AdventOfCode2025Day09 #Day9 #Day09 #Rust #RustLang #Programming #CodingChallenges

I'm so glad I'm writing the solutions in both #nim and Python because I tend to find ways to improve the Python solution with the Nim one and vice versa. Today was one of those days. The biggest thing I learned though is that solving these damned puzzles exhausted will never lead to good things quality-wise.

Solution: https://git.jamesthebard.net/jweatherly/advent-of-code/src/branch/main/2025/07/solution.nim

#aoc #aoc2025 #adventofcode #adventofcode2025 #programming #nim

Day 7 done.

Typical "don't even try brute-forcing it" part 2. I kept track of the timeline count as I worked my way vertically down the graph, and then added up the beams' shared timelines at the end. I also considered that dynamic programming with a recursive solution would probably have worked fine as well, but went for the approach that most matched the way I was already doing it.

I'll probably follow up with the dynamic programming approach, just for fun.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day7 #AdventOfCode2025Day07 #Day7 #Day07 #Rust #RustLang #Programming #CodingChallenges

This one took a smidge more thought as I can't abuse `zip` to rotate 2D sequences. However, just rewrote the rotation as a proc and used that. Instead of `reduce`, it was all `foldl`, and I fought with `char` vs `string` due to some of the processing operations between the normal and cephalopod problem processing.

Overall, definitely a fun solve.

Solution: https://git.jamesthebard.net/jweatherly/advent-of-code/src/branch/main/2025/06

#aoc #aoc2025 #adventofcode #adventofcode2025 #programming #nim

Day 6 done.

This was a funky one. Pretty easy for part 1. Just trimming, splitting, and parsing all the numbers and operators and grouping them columnwise. Nothing too hard.

Part 2 was awkward. I always am a bit flustered when I have to go back and parse the input differently, especially because I build things around FromStr in Rust, so I have to do either a Part2Input for the second part or a separate parsing function. This one was fiddly because I tried to parse it into the same Input structure as before, but that didn't work because not all the equations had the same quantity of numbers this time. I also wanted to do some sort of zip that let me zip over an iterator of iterators, but I couldn't find a good way of zipping a dynamic number of iterators, even in itertools (it has multizip, but that only works on a compiletime number of iterators). In the end, I needed to do this awkward loop:

number_buffer.clear();
for number_line_iterator in &mut number_line_iterators {
    match number_line_iterator.next() {
        Some(digit) => number_buffer.push(digit),
        None => {
            equations.push(Equation {
                numbers: numbers,
                operator: operators.next().unwrap(),
            });
            break 'outer;
        }
    }
}

Not the prettiest, but it did get the job done.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day6 #AdventOfCode2025Day06 #Day6 #Day06 #Rust #RustLang #Programming #codingchallenges

Day 5 done. Now this one was the easiest one so far. I was shocked at how simple part 2 was. Just combining all overlapping ranges and doing some simple arithmetic. I initially tried a linear search, and it finished in 1.5ms. Then I switched to a binary search, and now it finishes in 1.7ms. Do not underestimate the power of the processor cache line. If the fresh ranges list were much larger, the binary search would have sped it up, I'm sure.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day5 #AdventOfCode2025Day05 #Day5 #Day05 #Rust #RustLang #Programming #codingchallenges

Day 4 done. This was probably the easiest one so far, but it might be because I'm so used to the grid problems from previous years.

I felt like just doing the count for part 1 would end up forcing me to rewrite something, so I returned the coordinates, hoping they'd come in handy for part 2. Fortunately, they did, and my part 2 was a 10-second addition, just adding a loop around the part 1 function. The whole thing runs in about 86 milliseconds. I could probably optimize it by storing a neighbor count in each live cell, decrementing those in accessible neighbors on each removal, and maybe keeping them in a sorted vector via Rc<RefCell> or an internal Cell, but I'm happy with this right now.

Edit: I ended up doing the optimization anyway

This runs in 10ms now. It might even run a bit faster if I make the rolls keep track of their neighbors with weak refs too, to prevent lots of extra neighbor lookups in the HashSet. I'll experiment with that a tiny bit, but I'm not going to spend all too much effort on it, and probably won't add an update unless it is a big speed boost.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day4 #AdventOfCode2025Day04 #Day4 #Day04 #Rust #RustLang #Programming #codingchallenges

Advent of Code, day 2 done.

This one felt familiar. I remember previous years having digit grouping problems like this before. I remembered that doing it arithmetically in most cases performs much better than a string comparison, so that's how I approached this initially.

Out of curiosity, I also converted each ID into a string and did a chunk-wise comparison, and it performed really well, taking only about 50% more time than the arithmetic solution. I'm sure my arithmetic solution could be faster, though. I initially used a String to hold the id, then switched to a stack array, but that didn't improve the speed at all. Glibc's allocator is really fast these days.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day2 #AdventOfCode2025Day02 #Day2 #Day02 #Rust #RustLang #Programming #Coding

First day on Advent Of Code 2025, and I had to completely remind myself the difference between modulo and remainder. Already stumbled on part 2 because of how little arithmetic I have to do in my day to day work. Got through it, and the solution is pretty simple: https://forge.axfive.net/AdventOfCode/2025/src/commit/7c02d16698e949c24d7cbdc0f1661c643fcac823aee588a207b27f237b152584/src/bin/day01.rs

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day1 #AdventOfCode2025Day01 #Day1 #Day01 #Rust #RustLang #Programming #Coding