#adventofcode — Public Fediverse posts

For this one part 1 was relatively simple (parsing was the longest task), despite my basic bruteforce solution still needing more than 2s to find an answer.

For part 2 I was initially excited to finally implement Gaussian elimination by myself, but then realized it couldn't work because this was a minimization problem. A quick search showed me that it was an integer linear programming problem, which everyone recommended to solve with a library.
Despite my better judgement, I convinced myself that a DFS exploration could maybe work. And it did! ... on the example.

So in the end I caved and did it with z3 like most people. At least it seems that the z3 crate has greatly improved in the past 2 years, and my code using it is relatively simple.

I also found this fun thing on the Z3 C documentation: https://social.treehouse.systems/@Aissen/115699422672481929

#AdventOfCode #RustLang #z3

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

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

Up until now it feels like the advent of code problems were designed for array languages.

There are certainly problems that takes multiple lines of code to solve (some of the early problems last year had that property). We'll see what happens in the next few days, but this one was remarkably concise when solved in Kap.

Here are two separate functions that solve the two parts:

∇ solveDay7part1 {
    f ← @.≠ io:read "part07.txt"
    +/ ∊ (1↓f) ∧ ¯1↓ { (⍺>⍵) ∨ ∨/ ¯1 1 ⌽¨ ⊂⍺∧⍵ }\ f
}

∇ solveDay7part2 {
    +/ { (⍺×~⍵) + +/ ¯1 1 ⌽¨ ⊂⍺×⍵ }/ @.≠ io:read "part07.txt"
}

Part 2 was even shorter than part 1.

In both problems, the general approach is the same: Iterate over the rows, and update the correct state based on the locations of the splitters.

The second problem keeps track of the number of ways in which a certain cell can be reached, which means that the location of a beam is no longer just a boolean value, but a number indicating the number of ways in which this position can be reached. The result is then simply the sum of all beam values in the last row.

I also note that so far, most of the problems have not had weird edge cases. For example, in today's problem there were no cases of two splitters next to each other, or were there any splitters at the beginning or end of a line. If that had been the case, the solutions would be a bit more complicated.

#adventofcode #programming #kap #apl

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 was interesting. In part 2, you have to parse text vertically, in a way where array languages really shines (transposition of 2-dimensional data is just a single character).

The solution I came up with is... ok... I guess? It feels it should be possible to do it much more concisely than I did it, and I've seen solutions in other languages that are on the same order of magnitude in size compared to the Kap solution, which is not something you see very often.

In particular, I saw an amazing Ruby solution that puts mine to shame, and I say that even though I don't even know much Ruby and never really liked it that much.

I am kind of happy with the way I implemented the operation selection. I take advantage of the case function (docs). It computes both the sums and the multiplications, and then uses case to pick the correct set of results.

Kap can do this without computing the double computing results, since the results of the sums are lazy, and the individual results will only be computed when the result is read.

https://codeberg.org/loke/advent-of-code-kap/src/branch/master/advent-of-code-2025/part06.kap

#adventofcode #programming #kap #apl

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

We're still in the easy part of advent of code. I have still been able to solve them in a single line of code per problem.

For part 2, I used the reduction operator for iteration. A more classic APL solution would probably use ⍣ in order to conserve memory (even though in this case, you only iterate 12 times anyway, so it doesn't matter).

In general, using / for iteration in Kap is less ugly than in APL, since Kap has lazy evaluation, so in most cases you wouldn't materialise the array you're reducing over anyway, so it's often a simpler solution than to try to bend the power operator to do what you want, which is not always obvious. At least that's my preference.

https://codeberg.org/loke/advent-of-code-kap/src/branch/master/advent-of-code-2025/part03.kap

#adventofcode #programming #kap #apl

I was at work when I first read the problem. I also misread the problem such that I thought it was actually the problem as described in part 2.

So, I spent some time thinking about a way to solve it efficiently, since I assumed there were going to be huge ranges of numbers, and I needed a way to quickly filter out values.

When I finally took a look at the actual data, I realised that it was possible to brute-force, and the solution turned out to be much simpler.

∇ loadData {
    ,/ {…/⍎¨⍵}¨ (@-≠)⍛⊂¨ (@,≠)⍛⊂ ↑ io:read "part02.txt"
}

∇ solveDay2Part1 {
    +/ { a←10⊤⍵ ⋄ ⍵ × ∧/=⌿ 2 ¯1 ⍴ a,(2|≢a)⍴100 }¨ loadData 0
}

∇ solveDay2Part2 {
    +/ { a←10⊤⍵ ⋄ d←1,math:divisors ≢a ⋄ ⍵ × 1∊{ 1=≢∪ ¯1 ⍵ ⍴ a }¨ d }¨ (10≤)⍛/ loadData 0
}

#adventofcode #programming #kap #apl

These are my solutions for day 1. I always enjoy it when I can write the entire solution in a single line of code.

For part 1, the majority of the code is in the conversion of the input data. In part 2, the conversion code is exactly the same, but the solution is a bit longer.

The input conversion converts a string "L10" to -10, and "R10" to 10. Part 1 in then simply a matter of performing a sum scan over the values, take the results mod 100 and count how many zeroes there are.

Part 2 was a bit more annoying. I solved it by creating a sequence of all numbers that is processed, meaning that L5 R2 becomes 50 49 48 47 46 45 46 47. I then take the values mod 100 and count the number of zeroes, exactly like the previous solution.

∇ solveDay1part1 {
    +/0=100|+\50 , (¯1+2×@L=↑)«×»(⍎↓)¨ io:read "part01.txt"
}

∇ solveDay1part2 {
    +/0=100| {⍺,(↑⌽⍺)+(×⍵)×1+⍳|⍵}/ 50 , (¯1+2×@L=↑)«×»(⍎↓)¨ io:read "part01.txt"
}

#adventofcode #programming #kap #apl

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