|
| 1 | +--- Day 3: Mull It Over --- |
| 2 | + |
| 3 | + "Our computers are having issues, so I have no idea if we have any |
| 4 | + Chief Historians in stock ! You're welcome to check the warehouse, |
| 5 | + though," says the mildly flustered shopkeeper at the [1]North Pole |
| 6 | + Toboggan Rental Shop . The Historians head out to take a look. |
| 7 | + |
| 8 | + The shopkeeper turns to you. "Any chance you can see why our computers |
| 9 | + are having issues again?" |
| 10 | + |
| 11 | + The computer appears to be trying to run a program, but its memory |
| 12 | + (your puzzle input) is corrupted . All of the instructions have been |
| 13 | + jumbled up! |
| 14 | + |
| 15 | + It seems like the goal of the program is just to multiply some numbers |
| 16 | + . It does that with instructions like mul(X,Y) , where X and Y are each |
| 17 | + 1-3 digit numbers. For instance, mul(44,46) multiplies 44 by 46 to get |
| 18 | + a result of 2024 . Similarly, mul(123,4) would multiply 123 by 4 . |
| 19 | + |
| 20 | + However, because the program's memory has been corrupted, there are |
| 21 | + also many invalid characters that should be ignored , even if they look |
| 22 | + like part of a mul instruction. Sequences like mul(4* , mul(6,9! , |
| 23 | + ?(12,34) , or mul ( 2 , 4 ) do nothing . |
| 24 | + |
| 25 | + For example, consider the following section of corrupted memory: |
| 26 | + |
| 27 | + xmul(2,4)%&mul[3,7]!@^do_not_mul(5,5)+mul(32,64]then(mul(11,8)mul(8,5)) |
| 28 | + |
| 29 | + Only the four highlighted sections are real mul instructions. Adding up |
| 30 | + the result of each instruction produces 161 ( 2*4 + 5*5 + 11*8 + 8*5 ). |
| 31 | + |
| 32 | + Scan the corrupted memory for uncorrupted mul instructions. What do you |
| 33 | + get if you add up all of the results of the multiplications? |
| 34 | + |
| 35 | +--- Part Two --- |
| 36 | + |
| 37 | + As you scan through the corrupted memory, you notice that some of the |
| 38 | + conditional statements are also still intact. If you handle some of the |
| 39 | + uncorrupted conditional statements in the program, you might be able to |
| 40 | + get an even more accurate result. |
| 41 | + |
| 42 | + There are two new instructions you'll need to handle: |
| 43 | + * The do() instruction enables future mul instructions. |
| 44 | + * The don't() instruction disables future mul instructions. |
| 45 | + |
| 46 | + Only the most recent do() or don't() instruction applies. At the |
| 47 | + beginning of the program, mul instructions are enabled . |
| 48 | + |
| 49 | + For example: |
| 50 | + |
| 51 | + xmul(2,4)&mul[3,7]!^don't()_mul(5,5)+mul(32,64](mul(11,8)undo()?mul(8,5)) |
| 52 | + |
| 53 | + This corrupted memory is similar to the example from before, but this |
| 54 | + time the mul(5,5) and mul(11,8) instructions are disabled because there |
| 55 | + is a don't() instruction before them. The other mul instructions |
| 56 | + function normally, including the one at the end that gets re- enabled |
| 57 | + by a do() instruction. |
| 58 | + |
| 59 | + This time, the sum of the results is 48 ( 2*4 + 8*5 ). |
| 60 | + |
| 61 | + Handle the new instructions; what do you get if you add up all of the |
| 62 | + results of just the enabled multiplications? |
| 63 | + |
| 64 | +References |
| 65 | + |
| 66 | + 1. file:///2020/day/2 |
0 commit comments