Metadata
-
Date
-
Tagged
-
Part of series
- Advent of Code 2024 Day 1
- Advent of Code 2024 Day 2
- Advent of Code 2024 Day 3
- Advent of Code 2024 Day 4
- Advent of Code 2024 Day 5
- Advent of Code 2024 Day 6
- Advent of Code 2024 Day 7
- Advent of Code 2024 Day 8
- Advent of Code 2024 Day 9
- Advent of Code 2024 Day 10
- Advent of Code 2024 Day 11
- Advent of Code 2024 Day 12
- Advent of Code 2024 Day 13
- Advent of Code 2024 Day 14
- Advent of Code 2024 Day 15
- Advent of Code 2024 Day 16
- Advent of Code 2024 Day 17
- Advent of Code 2024 Day 18
- Advent of Code 2024 Day 19
- Advent of Code 2024 Day 20
-
Older post
-
Newer post
Advent of Code 2024 Day 9
Day 9: Disk Fragmenter
https://adventofcode.com/2024/day/9
Another day, another familiar location.
Today we are under the sea.
It was fun hearing this song in English, as the version I thought of was the Dutch one.
You meet an old pal, struggling with their hard drive, as it’s nearly full.
Today’s input is the (compressed) disk map for that hard drive.
An example input looks like this:
It contains information about files and free space on the disk.
The digits (so 0-9!) alternate between indicating:
- The amount of file blocks
- The amount of free space blocks
That means that this input would be:
- 2 block file
- 3 blocks of free space
- 3 blocks of file
- 3 blocks of free space
- 1 block file
- etc
Each file has a corresponding file ID, based on the order of files in the input. Being a computersciency question, those IDs start at 0 (lua mentioned)
So expanding this example input partially,
using a .
to represent free space block,
and the id of a file to represent each file block:
Parsing
Today is a day again where I could have done without any data structures. But I used one anyway, because it allowed me to not use a magic number to represent free space.
I parsed the input into a list where each item in that list is represented by a pair of:
- An amount of blocks
- The kind of block that is repeated that many times
Part 1
The amphipod wants to reclaim contigious space on the disk by moving file blocks one at a time. From the end of the disk, to the leftmost open space, over and over. At the end a big chunk of free space should be available at the end of the disk.
To see a neat visualisation of this process, check out the question text.
The final step is calculating a checksum on the moved filesystem.
For each file, calculate index_of_file_block * file_id
, sum all those up, and boom, sum checked!
The question asks what the checksum is for the resulting filesystem.
I started off my part1 by decompressing the thing I parsed. In hindsight, I could have parsed the data directly into this format … FOR PART 1.
This is a great while
loop opportunity.
Start a running index at the end of the filesystem list.
Process an item in that list and one by one move to the front of this list.
If the item in the list is an empty block, move backwards and continue looping.
Otherwise, check for the first free block, and place the current (file!) block there. Perform the ol’ switcheroo, if you will.
Part 2
That method made the hard drive even slower!
It introduced a bunch of fragmentation, and that’s bad.
Who would have thought?
New plan, moving entire files at a time. Move files to the leftmost chunck of free space blocks that can hold the file.
In code this is very similar. The decompressing step at the start of the function disappears, the check for free space gains a conditions, and the switching of the files gains an extra step in case I switch a smaller file into a bigger empty space.
Final code
I could combine the logic for part 1 and part 2 into one function, but, eeeeeeeh.