https://adventofcode.com/2025/day/10
Day twelve part two requires that all previous puzzles are complete. So.
My guess for day ten part two was too high. One way that might happen is if pressing one of the larger buttons could result in the smaller buttons having to be pressed more times. Is that even possible?
I’ve been working under the assumption that if I press the big buttons as many times as possible first, then I’ll always have the smallest possible number of button presses.
Case 1: press the large button, press the smaller button three times
Case 2: don’t press the large button, press the sma—yeah, that doesn’t make sense at all.
What about if there were two large buttons of equal size? Could the order of them make a difference?
Case 1: press large button A, then large button B cannot be pressed, press smaller buttons three times
Case 2: press large button B, then large button A cannot be pressed, press smaller buttons two times
That seems like it would be possible…
A (0, 1, 2) B (2, 3, 4) C (0, 1) D (0) E (1) F (2) G (3) H (4)
Targets {2, 2, 4, 4, 4}
A, A, B, B, G, G, H, H B, B, B, B, C, C
Yeah, there it is. The counter-case.
Here’s the minimal version in the puzzle format.
[...] (0, 1, 2) (2, 3, 4) (0, 1) (2) (3) (4) {2, 2, 4, 4, 4}
And I confirmed that my code generates a result of 8 whereas reordering the first two gives me a result of 6.
[...] (2, 3, 4) (0, 1, 2) (0, 1) (2) (3) (4) {2, 2, 4, 4, 4}
This doesn’t mean I need to throw away the assumption entirely. I just need to consider that if I’m choosing between two buttons of the same size then I need to explore both options and give the lower result.
So next time I run this it’ll take even longer than 23.75 hours. Oh joy.
…
Went for a walk. Got an idea.
I’m basically just searching sequences of numbers like this:
000112 0001222 00111 001122 0112222
Right now I’m tracking all the paths in the tree using recursive functions that keep a list of the buttons to choose from. What if I just track the number of button presses?
[3, 2, 1]
[3, 1, 3]
[2, 3]
[2, 2, 2]
[1, 2, 4]
^ like that. Might take out a huge amount of overhead. But what’s the algorithm?
- Press the current button as many times as possible then move to the next button.
- If the last button has been pressed as many times as possible and there are non-zero joltages, decrement the previous non-zero button and repeat.
- If trying to decrement the first button when it’s already at zero then the search is complete.
I need to remember this doesn’t address the problem I just discovered. I’ll use this to try to speed it up first, then tackle the fix for that.
…
So for the grouped buttons I will need to explore every permutation of button presses for buttons that have the same size.
So if the button sizes are 3, 2, 2, 2, 1. Then I press the 3-size button as many times as possible and then the 2-size buttons in different orders:
0, 1, 2
0, 2, 1
1, 0, 2
1, 2, 0
2, 0, 1
2, 1, 0
As the number of buttons with the same number of wires goes up, the search tree grows exponentially.
…
Errors on 32 and 50.
32 / 177
Joltages: [2, 26, 24, 26]
Buttons: [[0, 1], [1, 3], [1, 2], [2, 3]]
Num presses: -1
ERROR
50 / 177
Joltages: [23, 26, 4, 27, 17]
Buttons: [[0, 1, 3], [1, 4], [0, 2, 3], [0, 3, 4], [1, 2, 3]]
Num presses: -1
ERROR
K, 17058 is the result with those two cases return -1 so I need to add the actual solutions to those two to 17060 and hopefully that’s my number.
My old implementation gives me 50 and 43 for those two. The old implementation is not always right, sometimes too high, so let’s see if this works.
17153
Too high. Damn. At least it’s incorrect in the expected direction.