You enter a tall, narrow chamber.
Rocks start falling.
For some reason, there’s a loud song playing in this room.
Very mysterious stuff!
I don’t mind, it’s a bop.
The falling rocks have these shapes, where # is rock and . is air:
The “pieces” fall in that order, wrapping when the end of that list of 5 pieces is reached.
Jets of steam push around the rocks as they fall.
Today’s puzzle input is the sequence of directions the pieces will be pushed in.
An example input looks like this:
< means a jet of air that blows a piece left
> means a jet of air that blows a piece right
As with the pieces, if the end of the list is reached, it repeats.
The chamber is exactly seven units wide.
Each piece appears so that its left edge is two units away from the left wall and its bottom edge is three units above the highest rock in the room (or the floor, if there isn’t one).
After a piece appears, it alternates between being pushed by a jet of hot gas one unit and falling down one unit.
If a movement would cause the piece to move into the walls, the floor, or an other piece, that movement doesn’t happen.
When a piece is prevented from falling, a new piece immediately begins falling.
Parsing
The jets are an instance of a Jet enum that’s Left or Right.
The input is a list of them.
I’m also counting getting those pieces into useful data structure as parsing today.
Oh, and I’m also storing the width of the chamber in a constant.
I chose to represent the pieces as a series of point offsets to a point.
Point? You know what that means, Coord is back for an other appearance!
Each Coord offset represents a rock in the piece.
Part 1
The question asks how tall the tower of rocks will be when 2022 pieces stopped falling.
The instructions in pseudocode:
I grouped a couple of variables to keep track of the state of the chamber in a struct:
At the start of the simulation, every number starts at 0, and the map is empty.
jet_count is a number to keep track of how many jets in total have blown.
piece_count is a number to keep track of how many pieces in total have started falling.
top is a number to keep track of how tall the tower currently is
map is a list of 7 wide boolean arrays, each keeping track of where settled rocks are at that height.
curr is the coordinate pair where the offsets of a piece will apply to in order to figure out where the rocks of a piece are.
When a piece stops falling, it is added to the map list.
Helpers
A helper to determine given a new curr coordinate, if the state using that as curr would be valid.
The only wall collision that is checked is the one with the right wall.
This is because a Coord has fields that can only ever be 0 or greater
Collisions with other pieces are checked by indexing into map and seeing if a rock is there.
Because this was a finnicky problem to get right, I implemented Display so I could print out the state of the chamber.
This takes the list of booleans in map and turns them into:
# for true
. for false
It then creates empty rows to fit the current piece if necessary.
For every offset in the current piece, it adds a @ to that map.
That map is then printed to the screen with | on the sides or each row.
And at the bottom, a +-----+, just like the examples in the question!
That way, in the solution code I can pop in a println!("{}", state); and see the same output as in the question text.
This was an awesome tool for finding off by one errors (and there were a lot of those)
The code for part1 has the locations where that printing of the state is used commented out.
Final code
Part 2
The elephants with you are not impressed.
They would like to know how tall the tower will be after 1000000000000 pieces have stopped.
That’s a lot of zeros.
A trillion rocks! Must be quite a high chamber, eh?
The question asks how tall the tower of rocks will be when 1000000000000 pieces stopped falling.
Changing the 2022 to a trillion in the code above would provide a correct answer.
The only question is, am I willing to wait the time it takes to complete?
The answer is no.
Luckily, there is a pattern in the dropped rocks that repeats.
Part 2 is about finding that repetition and fast forwarding as close to that trillion as possible.
To help with that, a few extra fields for the State struct:
A seen key is a combination of the index into PIECES and the index into jets.
A cycle can only be detected the third time we encounter such a pair though.
This is because some of the first pieces will have hit the floor.
By the time a combination of pieces_idx, jets_idx comes around again, the fallen blocks only interact with other blocks when falling.
That is the first repeatable cycle.
The seen values are:
A counter of how many times a key was seen
The pieces_count at that time
The top at that time
Using those 2 last pieces of information, the difference in top between now and the previous time we encountered a (pieces_idx, jet_idx) pair can be calculated.
We fast forward as much times as we can without hitting the trillion.
The increase in top that would have caused is stored in amount_added.
The remaining amount to the trillion is simulated as before.
Final code
I then made a method with that logic to reuse it between part 1 and part 2.