Day 7: Bridge Repair

2024-12-07

The Historians take you to a familiar rope bridge over a river in the middle of a jungle. The Chief isn't on this side of the bridge, though; maybe he's on the other side?

When you go to cross the bridge, you notice a group of engineers trying to repair it. (Apparently, it breaks pretty frequently.) You won't be able to cross until it's fixed.

You ask how long it'll take; the engineers tell you that it only needs final calibrations, but some young elephants were playing nearby and stole all the operators from their calibration equations! They could finish the calibrations if only someone could determine which test values could possibly be produced by placing any combination of operators into their calibration equations (your puzzle input).

For example:

1
2
3
4
5
6
7
8
9
190: 10 19 3267: 81 40 27 83: 17 5 156: 15 6 7290: 6 8 6 15 161011: 16 10 13 192: 17 8 14 21037: 9 7 18 13 292: 11 6 16 20

Each line represents a single equation. The test value appears before the colon on each line; it is your job to determine whether the remaining numbers can be combined with operators to produce the test value.

Operators are always evaluated left-to-right, not according to precedence rules. Furthermore, numbers in the equations cannot be rearranged. Glancing into the jungle, you can see elephants holding two different types of operators: add (+) and multiply (*).

Only three of the above equations can be made true by inserting operators:

  • 190: 10 19 has only one position that accepts an operator: between 10 and 19. Choosing + would give 29, but choosing * would give the test value (10 * 19 = 190).
  • 3267: 81 40 27 has two positions for operators. Of the four possible configurations of the operators, two cause the right side to match the test value: 81 + 40 * 27 and 81 * 40 + 27 both equal 3267 (when evaluated left-to-right)!
  • 292: 11 6 16 20 can be solved in exactly one way: 11 + 6 * 16 + 20.

The engineers just need the total calibration result, which is the sum of the test values from just the equations that could possibly be true. In the above example, the sum of the test values for the three equations listed above is 3749.

Determine which equations could possibly be true. What is their total calibration result?

Progress: 0 / 850
Total: 0

This had a few really fun parts! First, I got a new utility function out of this:

1
2
3
4
5
function* cartesianIterator<T>(items: T[][]): Generator<T[]> { const remainder = items.length > 1 ? cartesianIterator(items.slice(1)) : [[]]; for (let r of remainder) for (let h of items.at(0)!) yield [h, ...r]; }

I could call this function with [ "+", "*" ] * (# of variables - 1)] to get all of the possible combinations of the operators. For example, calling this on a formulas with 5 variables will return this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[ [ "+", "+", "+", "+" ], [ "*", "+", "+", "+" ], [ "+", "*", "+", "+" ], [ "*", "*", "+", "+" ], [ "+", "+", "*", "+" ], [ "*", "+", "*", "+" ], [ "+", "*", "*", "+" ], [ "*", "*", "*", "+" ], [ "+", "+", "+", "*" ], [ "*", "+", "+", "*" ], [ "+", "*", "+", "*" ], [ "*", "*", "+", "*" ], [ "+", "+", "*", "*" ], [ "*", "+", "*", "*" ], [ "+", "*", "*", "*" ], [ "*", "*", "*", "*" ] ]

Then I can iterate through the operator combinations and check to see if the result matches the formula. The easiest way to do this is through JavaScript's eval function.

Note that we need to keep a running result as we work through each operator, we can't simply construct the full formula at once and eval it a single time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
const operators = ["+", "*"] as const; const operatorCombos = [ ...cartesianIterator(Array(variables.length - 1).fill([...operators])), ] as Array<Array<string>>; let solved = ""; operatorCombos.forEach((operators) => { // Early exit if we've solved this already if (solved) return; let rightHand = variables[0]; operators.forEach((operator, index) => { // index + 1 because we've skipped the first variable rightHand = eval(`${rightHand} ${operator} ${variables[index + 1]}`); }); if (eval(rightHand) === result) { solved = rightHand; } });

The engineers seem concerned; the total calibration result you gave them is nowhere close to being within safety tolerances. Just then, you spot your mistake: some well-hidden elephants are holding a third type of operator.

The concatenation operator (||) combines the digits from its left and right inputs into a single number. For example, 12 || 345 would become 12345. All operators are still evaluated left-to-right.

Now, apart from the three equations that could be made true using only addition and multiplication, the above example has three more equations that can be made true by inserting operators:

  • 156: 15 6 can be made true through a single concatenation: 15 || 6 = 156.
  • 7290: 6 8 6 15 can be made true using 6 * 8 || 6 * 15.
  • 192: 17 8 14 can be made true using 17 || 8 + 14.

Adding up all six test values (the three that could be made before using only + and * plus the new three that can now be made by also using ||) produces the new total calibration result of 11387.

Using your new knowledge of elephant hiding spots, determine which equations could possibly be true. What is their total calibration result?

Progress: 0 / 850
Total: 0

The solution is nearly identical to Part 1, but with added support for the new operator.

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
const operators = ["+", "*", "||"] as const; const operatorCombos = [ ...cartesianIterator(Array(variables.length - 1).fill([...operators])), ] as Array<Array<string>>; let solved = ""; operatorCombos.forEach((operators) => { // Early exit if we've solved this already if (solved) return; let rightHand = variables[0]; operators.forEach((operator, index) => { // index + 1 because we've skipped the first variable if (operator === "||") { rightHand = eval(`${rightHand}${variables[index + 1]}`); } else { rightHand = eval(`${rightHand} ${operator} ${variables[index + 1]}`); } }); if (eval(rightHand) === result) { solved = rightHand; } });
Part 1 TimePart 1 RankPart 2 TimePart 2 Rank
00:31:365,52700:35:414,394

This added operator in Part 2 causes the code to take MUCH longer to run:

$$ \text{(# possible formulas)} = \text{(# operators)} ^ {(\# variables - 1)} $$

Let's take a look at a few examples.

My first input:

28636455986: 659 218 6 1 724 6

In this row, we've got 6 variables. In Part 1, there are 32 formulas to check. In Part 2, there are 243 formulas to check.

$$ \text{Part 1}: \text{(32 formulas)} = \text{(2 operators)} ^ {((6 - 1) variables)} $$ $$ \text{Part 2}: \text{(243 formulas)} = \text{(3 operators)} ^ {((6 - 1) variables)} $$

Not too bad for this example. But if we look at another input:

46173790364056: 8 548 2 7 6 115 1 5 62 9

In this row, we've got 10 variables. In Part 1, there are 512 formulas to check. In Part 2, there are 19,683 formulas to check.

$$ \text{Part 1}: \text{(512 formulas)} = \text{(2 operators)} ^ {((10 - 1) variables)} $$ $$ \text{Part 2}: \text{(19,683 formulas)} = \text{(3 operators)} ^ {((10 - 1) variables)} $$

As the number of variables increases, the number of formulas to check grows exponentially. If we hit a correct formula early, we'll exit the check for that row early. But if the correct formula happens to be one of the last formulas we check, suddenly our code takes much longer to reach a final result.