6
votes
Day 6: Trash Compactor
Today's problem description: https://adventofcode.com/2025/day/6
Please post your solutions in your own top-level comment. Here's a template you can copy-paste into your comment to format it nicely, with the code collapsed by default inside an expandable section with syntax highlighting (you can replace python with any of the "short names" listed in this page of supported languages):
<details>
<summary>Part 1</summary>
```python
Your code here.
```
</details>
"It's no use, Mr. James--it's generators all the way down."
Much easier today than yesterday, I think. Though the values not being left- or right-aligned in the columns was a wrinkle for Part 02. As others have said, the actual problem is solved quickly and in only a few lines. The rest is parsing an input format that's more annoying than interesting.
Part 1
Part 2
Well, I figured we'd get to the parsing puzzle eventually. I got stuck for a while after I realized the columns weren't all the same size in the real input. I'm not especially happy with my parsing logic, but it appears to do the job, and at this point I think I'm better off not messing with it any further.
I will admit I tend to dislike these kinds of puzzles somewhat, since parsing text formats (especially column-based ones like this) is pretty finicky and not all that enjoyable to me. This one was at least interesting, though - I'll give it that.
Solution (Lily)
Yeah, it's supposed to be fun after all. I do wonder though, would it be cleaner to separate the parsing for part 1 and part 2? At least that's the approach I took.
Possibly that would be cleaner, yeah, though maybe less efficient. I did update my code today to parse from right-to-left rather than left-to-right, which simplified things a little bit.
Pulling things out of my posterior orifice here, I didn't even log in to see the actual inputs, but wouldn't:
this
Doing a text operation replacing all `" "` (double spaces) with `" "`, stripping leftover spaces before the first and after the last digit per row, then splitting rows by `"\n"` and columns by `" "`That’s basically what my first attempt did, and it worked for Part 1. The problem is that in Part 2, the number and positions of those extras spaces actually matter quite a bit. My solution that accounts for that was to infer the width of each column by measuring the distance between its operator and the next one in the bottom row, then extract all the numbers from that column as strings (with space characters intact) using the right-sized window.
Ack, I solved Part 1 pretty quickly but Part 2 is throwing me for a loop. Need to reverse course on most of my assumptions that held Part 1 together, namely the way my input formatting collapses adjacent spaces to make parsing easier. It's getting too late for me now, I'll need to sleep on it and refactor this thing in the morning.
Probably a good opportunity to rethink my string -> number -> string -> number conversion strategy too, let's just say TypeScript is not happy with some of the stuff I've been doing in my current state of sleepy delirium lol...
Yesterday was rough. After trying a long time, I gave up on solving the range merging and resorted to copying some code off Google (not specifically AoC code, so not technically cheating, but it felt like a moral loss). Today on the other hand was a big morale boost. I actually bought a physical notepad with grid paper to sketch things out, but in the end I didn't need it for this problem, although it might come in handy later!
Part 2 solution (Python)
Elixir
Both Parts
Benchmarks
Notes:
Blegh, this was an odyssey for all the wrong reasons for me.
I breezed through part one and even though I basically had to rewrite for part two, I quickly had a solution that satisfied the demo.
BUT IT WOULD NOT PASS.
Why, why, I lamented. Well it turned out after painstaking searches and debugging, that my program's core logic had no fault! It worked! However, there was a little detail:
Enum.zip(), which I used to transform the rows of numbers into columns, stops once any of the Enumerables are empty. Which should not be a problem, right? The lines all have the same length! The text file was even properly formatted after all, all nice and tidy!Except, in my infinite wisdom, I had given my file-reading-helper a little convenience: It trimmed the input string. Which deleted the trailing newline. Which made the last line shorter by one char. Which meant the last column wasn't being processed.
Blegh.
Yeah, I got bit with something similar. Nothing I had coded myself, but I always get my input into place by pasting the AoC input content into a local file in my VS Code project. This method has always worked fine for me but thanks to today’s puzzle I just realized that the IDE’s auto-format rules “helpfully” trim all whitespace from the end of every line, even in unknown file types. Which completely breaks this puzzle input. That was annoying.
I had to copy the input into Notepad++ instead of Sublime Text, since my Sublime config automatically trims trailing whitespace. It pays to have more than one editor around, I suppose. (I think if you put a cursor at the end of every line Sublime won't do it, though - maybe that's also the case in VS Code?)
Yeah, I just pulled up vim and pasted it in there. Thankfully it was an easy problem to solve, just a tricky one to identify in the first place.
my head is not in the game this year. Anyway, here's P1
Google Sheets
Today was a weird one. Numpy does not like how big these numbers get (leading to overflows), so there's a lot of ugly typecasting. If there's any numpy experts around here, I'd love to know how I could improve this (other than just writing the rotation function myself, which I considered but decided against).
Parts 1 and 2 (Python)
The problem is that when you pass
paramstooperatein part 2, it isn't a numpy array, so whennumpy.prod()auto-converts it to one, it defaults the datatype toint32and overflows. You can fix it withnumpy.prod(params, dtype='uint64').As for the rotation, using
list(zip(*inputs))[::-1]is a neat trick if you want to do the rotations yourself.Thanks! In Part 1 I found that
numpy.rot90()output a int32 numpy array, and I couldn't figure out how to set the dtype on it (still don't know how), so I didn't even think about that when working on Part 2. It looks like passing the proper dtype tonumpy.prod()makes it all work properly and I can get rid of a few casts.That rotation is pretty neat. I probably wouldn't have figured that out on my own, but I'm still trying to figure out all the tricks python (and some of its common libraries) have to offer. I see that someone else used
itertools.zip_longestwhich seems to do something similar, but doesn't truncate if the inputs are different lengths.Another day down, though this was mostly just a bit annoying. I did add a few useful tools to my saved utilities:
transpose/2,split_list/3, andprod_list/2. Not sure if they'll be useful in future days, but I thought they were general enough to keep.Prolog Solution
Utilities
Not the most interesting day for me since this was only about parsing the input the right way, without any shred of thinking to be had on the algorithm side.
What's funny is that it would have been much faster for me to first tackle the 2nd part, followed by the first part since the first part is just the second part with the two loops parsing numbers needing to be swapped.
Solution (Rust)
TypeScript
Okay, got my actual solution figured out now. The breakthrough was realizing that the operators (in the last row) always appear in the same position within each column, even though the numbers above them shift around. So I begin by walking that bottom row, using each operator as a delimiter which indicates the size (number of characters) in the previous column. Only caveat was that since there's no delimiter to mark the end of the last column, I needed a bit of special kludge to handle that case correctly.
Once I have the information for a given column — still within that bottom-row walk loop — I can assemble an array of "numbers" (but I'm keeping them as strings to preserve digit placement) for the math problem represented by that column. I store the operator for that problem in my data structure too, so the final formatted data is an array of
MathProblemobjects that look like this:Then I leave the logic for handling that formatted data up to the Parts 1 and 2 logic. Part 1 is easy, I just call
numbers.join(operation)to merge them into a string that looks like this:"123* 45* 6"and then I pass that toeval(). It handles the number parsing and math and doesn't care about the irregular whitespace. Part 2 is a little trickier but just boils down to assembling different "number" strings by getting the length of the existing ones and iterating that many times, and concatenating all of the characters from each existing one that share the same index.It's harder to write this in plain English than it was to just code it, lol...
Parts 1 and 2
Benchmarks: The median formatting time on my machine over 50 iterations was 97µs, Part 1 was 242µs, and Part 2 was 482µs.