1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
--- Day 16: Ticket Translation ---
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 [1m[37mread[0m the words on the ticket. You can, however, read
the numbers, and so you figure out [1m[37mthe fields these tickets must have[0m and [1m[37mthe
valid ranges[0m for values in those fields.
You collect the [1m[37mrules for ticket fields[0m, the [1m[37mnumbers on your ticket[0m, and
the [1m[37mnumbers on other nearby tickets[0m for the same train service (via the airport
security cameras) together into a single document you can reference (your puzzle input).
The [1m[37mrules for ticket fields[0m specify a list of fields that exist [1m[37msomewhere[0m
on the ticket and the [1m[37mvalid ranges of values[0m 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).
Each ticket is represented by a single line of comma-separated values. The values are the numbers on
the ticket in the order they appear; every ticket has the same format. For example, consider this
ticket:
.--------------------------------------------------------.
| ????: 101 ?????: 102 ??????????: 103 ???: 104 |
| |
| ??: 301 ??: 302 ???????: 303 ??????? |
| ??: 401 ??: 402 ???? ????: 403 ????????? |
'--------------------------------------------------------'
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
[1m[37mmuch[0m 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 [1m[37mcompletely invalid[0m; these are tickets that
contain values which [1m[37maren't valid for any field[0m. Ignore [1m[37myour ticket[0m for
now.
For example, suppose you have the following notes:
class: 1-3 or 5-7
row: 6-11 or 33-44
seat: 13-40 or 45-50
your ticket:
7,1,14
nearby tickets:
7,3,47
40,[1m[37m4[0m,50
[1m[37m55[0m,2,20
38,6,[1m[37m12[0m
It doesn't matter which position corresponds to which field; you can identify invalid
[1m[37mnearby tickets[0m by considering only whether tickets contain [1m[37mvalues that are not
valid for any field[0m. In this example, the values on the first [1m[37mnearby ticket[0m are all
valid for at least one field. This is not true of the other three [1m[37mnearby tickets[0m: the
values 4, 55, and 12 are are not valid for any field. Adding together all of the invalid values
produces your [1m[37mticket scanning error rate[0m: 4 + 55 + 12 = [1m[37m71[0m.
Consider the validity of the [1m[37mnearby tickets[0m you scanned. [1m[37mWhat is your ticket
scanning error rate?[0m
|
