Advent of Code 2020: Day 16
, 11 min readadvent of code 2020
Part 1
As you’re walking to yet another connecting flight, you realize that one of the legs of your re-routed trip coming up is on a high-speed train. However, the train ticket you were given is in a language you don’t understand. You should probably figure out what it says before you get to the train station after the next flight.
Unfortunately, you can’t actually read the words on the ticket. You can, however, read the numbers, and so you figure out the fields these tickets must have and the valid ranges for values in those fields.
You collect the rules for ticket fields, the numbers on your ticket, and the numbers on other nearby tickets for the same train service (via the airport security cameras) together into a single document you can reference (your puzzle input).
The rules for ticket fields specify a list of fields that exist somewhere on the ticket and the valid ranges of values for each field. For example, a rule like class: 1-3 or 5-7 means that one of the fields in every ticket is named class and can be any value in the ranges 1-3 or 5-7 (inclusive, such that 3 and 5 are both valid in this field, but 4 is not).
For example, consider this ticket:
|
|
Here, ? represents text in a language you don’t understand. This ticket might be represented as 101,102,103,104,301,302,303,401,402,403; of course, the actual train tickets you’re looking at are much more complicated. In any case, you’ve extracted just the numbers in such a way that the first number is always the same specific field, the second number is always a different specific field, and so on - you just don’t know what each position actually means!
Start by determining which tickets are completely invalid; these are tickets that contain values which aren’t valid for any field. Ignore your ticket for now.
Consider the validity of the nearby tickets you scanned. What is your ticket scanning error rate?
You can read the full text here. For those of you who have been reading my blogs, or taking part in puzzles yourself, this problem should feel very familiar to day 4. The first part of today’s is entirely data parsing and data validation. We need to read in all of the ticket field rules and store them. After that, we can read in each ticket and validate all of the numbers on the ticket.

We’re going to start by setting up a class
called Field
which stores the rules for a given field on the ticket. We can then write a validator method, valid
which we can call to check if a number is valid for the given Field
. In C++, this could be implemented as follows:
|
|
This class
contains the name of the field, the two ranges that the number on the ticket must lay within, and the column (which we are ignoring for part 1). We have also defined a constructor and the validator which are fairly straightforward. The validator returns 1 if the number is within one of the two ranges, and it returns 0 otherwise. Thus, we can now loop through the rules of the form,
|
|
and generate Field
s. To achieve this we are going to use regex to process the line,
|
|
The line above will match the initial words, along with their spaces before moving on to match the 4 numbers included in the range. We can then loop through every one of these rules, applying regex and creating the corresponding Field
object and storing them in a vector
.
|
|
Excellent! Now we have a vector
of fields, each of which has it’s own validator method which we can call on any value.
Now we need to read in the tickets which are stored like this,
|
|
We have many lines each of which contains 20 comma-separated numbers, representing a ticket. To parse these we are going to use a new regex pattern which just identifies numbers,
|
|
Perfect, we now have a vector
of vector
s which store integer
s for the value on each ticket.
We now loop through each value, on each ticket and ensure that it is valid for at least one of the rules that we stored. We can do this with the following code:
|
|
As soon we find a field that the value is valid for we move on to checking the next value. Suppose the value is not valid for any field. We add it to our answer and mark the ticket as invalid in our invalid vector
, which is something we need in part 2. But, for now, all we need to do is sum the invalid numbers, and we have the first ⭐!
Part 2
Now that you’ve identified which tickets contain invalid values, discard those tickets entirely. Use the remaining valid tickets to determine which field is which.
Using the valid ranges for each field, determine what order the fields appear on the tickets. The order is consistent between all tickets: if the seat is the third field, it is the third field on every ticket, including your ticket.
Once you work out which field is which, look for the six fields on your ticket that start with the word departure. What do you get if you multiply those six values together?
You can read the full text here. Well, part 2 is a little tricker, as expected. We now need to work out which column corresponds to which field on the ticket.
We are going to solve part 2 in two steps. For the first step we will loop through every field, and every column of numbers of the tickets. We can then check if every value in that column is valid for the given field, if so, we will store this as a possible column for that field. If any value is not valid, then that column cannot be represent that field. Our C++ code for this is as follows:
|
|
where for each field, we loop over every column in every ticket to see if that column is a possible candidate for the outer field. If the column is a possibility, then we store it as a possibility in a list
in the Field
class. This process will return results similar to those shown below:
|
|
Which says field “a” could be column 1, and field “b” could be column 1 or 3, and so on. We now repeatedly iterate over the output and eliminate redundant options. As field “a” can only be column 1, we can remove column 1 from all of the other fields,
|
|
Now we know that field “b” is column 3; thus, field “c” cannot be column 3,
|
|
and by completing the logic puzzle and eliminating solved columns we can reach a determinant answer. We can do this in code with the following:
|
|
After a few iterations, we have deduced which column corresponds to each field. Then we just have to find the “departure” fields in our own ticket, ticket 0, and return the product.
|
|
There we go, ⭐⭐!
Reflections
I think my code for today’s puzzle was reasonably readable. In particular, making a class
to store each field with a validator helped make the code slightly less imperative, and thus more readable. However, I probably could, and should have factored out a little more code into smaller functions.
Today’s puzzle was not so much an exercise in algorithms for part 1, but more data parsing. Nonetheless, we did make some algorithmic decisions. Namely, we chose to read in every rule, and then subsequently read in and store every ticket. We then do a single pass over each value, in each ticket and check it against every field. Thus the complexity of part 1 scales, at worst, as O(N * M * M)
in time and O(N * M)
in space where N
is the number of tickets, and M
is the number of fields.
For part 2, we end up checking every column of every ticket for every field. Thus, as before this initially scales the same as part 1, O(N * M * M)
-time and O(N * M)
-space. Then later in part 2, we must also perform our process of elimination which scales in time as O(M * M)
. Thus, overall, the entire solution scaled the same as part 1.
I hope you enjoyed today’s puzzle, even if data parsing and validation is not your thing. See you tomorrow!
I have no affiliation with AoC. I’m just a fan of the programming puzzles. If you enjoy them too, please feel free to join in and support the creators