242 lines
8.7 KiB
Plaintext
242 lines
8.7 KiB
Plaintext
|
[1]Advent of Code
|
|||
|
|
|||
|
• [2][About]
|
|||
|
• [3][Events]
|
|||
|
• [4][Shop]
|
|||
|
• [5][Settings]
|
|||
|
• [6][Log Out]
|
|||
|
|
|||
|
br0xen [7](AoC++) 40*
|
|||
|
|
|||
|
{:year [8]2023}
|
|||
|
|
|||
|
• [9][Calendar]
|
|||
|
• [10][AoC++]
|
|||
|
• [11][Sponsors]
|
|||
|
• [12][Leaderboard]
|
|||
|
• [13][Stats]
|
|||
|
|
|||
|
Our [14]sponsors help make Advent of Code possible:
|
|||
|
[15]Boot.dev - Ready to become a backend developer? If you like AoC, you
|
|||
|
might be like us. We think smartest way to learn to code is to ensure
|
|||
|
youʼre never bored. Try the most captivating, addictive way to learn to
|
|||
|
code on Boot.dev.
|
|||
|
|
|||
|
--- Day 20: Pulse Propagation ---
|
|||
|
|
|||
|
With your help, the Elves manage to find the right parts and fix all of
|
|||
|
the machines. Now, they just need to send the command to boot up the
|
|||
|
machines and get the sand flowing again.
|
|||
|
|
|||
|
The machines are far apart and wired together with long cables. The cables
|
|||
|
don't connect to the machines directly, but rather to communication
|
|||
|
modules attached to the machines that perform various initialization tasks
|
|||
|
and also act as communication relays.
|
|||
|
|
|||
|
Modules communicate using pulses. Each pulse is either a high pulse or a
|
|||
|
low pulse. When a module sends a pulse, it sends that type of pulse to
|
|||
|
each module in its list of destination modules.
|
|||
|
|
|||
|
There are several different types of modules:
|
|||
|
|
|||
|
Flip-flop modules (prefix %) are either on or off; they are initially off.
|
|||
|
If a flip-flop module receives a high pulse, it is ignored and nothing
|
|||
|
happens. However, if a flip-flop module receives a low pulse, it flips
|
|||
|
between on and off. If it was off, it turns on and sends a high pulse. If
|
|||
|
it was on, it turns off and sends a low pulse.
|
|||
|
|
|||
|
Conjunction modules (prefix &) remember the type of the most recent pulse
|
|||
|
received from each of their connected input modules; they initially
|
|||
|
default to remembering a low pulse for each input. When a pulse is
|
|||
|
received, the conjunction module first updates its memory for that input.
|
|||
|
Then, if it remembers high pulses for all inputs, it sends a low pulse;
|
|||
|
otherwise, it sends a high pulse.
|
|||
|
|
|||
|
There is a single broadcast module (named broadcaster). When it receives a
|
|||
|
pulse, it sends the same pulse to all of its destination modules.
|
|||
|
|
|||
|
Here at Desert Machine Headquarters, there is a module with a single
|
|||
|
button on it called, aptly, the button module. When you push the button, a
|
|||
|
single low pulse is sent directly to the broadcaster module.
|
|||
|
|
|||
|
After pushing the button, you must wait until all pulses have been
|
|||
|
delivered and fully handled before pushing it again. Never push the button
|
|||
|
if modules are still processing pulses.
|
|||
|
|
|||
|
Pulses are always processed in the order they are sent. So, if a pulse is
|
|||
|
sent to modules a, b, and c, and then module a processes its pulse and
|
|||
|
sends more pulses, the pulses sent to modules b and c would have to be
|
|||
|
handled first.
|
|||
|
|
|||
|
The module configuration (your puzzle input) lists each module. The name
|
|||
|
of the module is preceded by a symbol identifying its type, if any. The
|
|||
|
name is then followed by an arrow and a list of its destination modules.
|
|||
|
For example:
|
|||
|
|
|||
|
broadcaster -> a, b, c
|
|||
|
%a -> b
|
|||
|
%b -> c
|
|||
|
%c -> inv
|
|||
|
&inv -> a
|
|||
|
|
|||
|
In this module configuration, the broadcaster has three destination
|
|||
|
modules named a, b, and c. Each of these modules is a flip-flop module (as
|
|||
|
indicated by the % prefix). a outputs to b which outputs to c which
|
|||
|
outputs to another module named inv. inv is a conjunction module (as
|
|||
|
indicated by the & prefix) which, because it has only one input, acts like
|
|||
|
an inverter (it sends the opposite of the pulse type it receives); it
|
|||
|
outputs to a.
|
|||
|
|
|||
|
By pushing the button once, the following pulses are sent:
|
|||
|
|
|||
|
button -low-> broadcaster
|
|||
|
broadcaster -low-> a
|
|||
|
broadcaster -low-> b
|
|||
|
broadcaster -low-> c
|
|||
|
a -high-> b
|
|||
|
b -high-> c
|
|||
|
c -high-> inv
|
|||
|
inv -low-> a
|
|||
|
a -low-> b
|
|||
|
b -low-> c
|
|||
|
c -low-> inv
|
|||
|
inv -high-> a
|
|||
|
|
|||
|
After this sequence, the flip-flop modules all end up off, so pushing the
|
|||
|
button again repeats the same sequence.
|
|||
|
|
|||
|
Here's a more interesting example:
|
|||
|
|
|||
|
broadcaster -> a
|
|||
|
%a -> inv, con
|
|||
|
&inv -> b
|
|||
|
%b -> con
|
|||
|
&con -> output
|
|||
|
|
|||
|
This module configuration includes the broadcaster, two flip-flops (named
|
|||
|
a and b), a single-input conjunction module (inv), a multi-input
|
|||
|
conjunction module (con), and an untyped module named output (for testing
|
|||
|
purposes). The multi-input conjunction module con watches the two
|
|||
|
flip-flop modules and, if they're both on, sends a low pulse to the output
|
|||
|
module.
|
|||
|
|
|||
|
Here's what happens if you push the button once:
|
|||
|
|
|||
|
button -low-> broadcaster
|
|||
|
broadcaster -low-> a
|
|||
|
a -high-> inv
|
|||
|
a -high-> con
|
|||
|
inv -low-> b
|
|||
|
con -high-> output
|
|||
|
b -high-> con
|
|||
|
con -low-> output
|
|||
|
|
|||
|
Both flip-flops turn on and a low pulse is sent to output! However, now
|
|||
|
that both flip-flops are on and con remembers a high pulse from each of
|
|||
|
its two inputs, pushing the button a second time does something different:
|
|||
|
|
|||
|
button -low-> broadcaster
|
|||
|
broadcaster -low-> a
|
|||
|
a -low-> inv
|
|||
|
a -low-> con
|
|||
|
inv -high-> b
|
|||
|
con -high-> output
|
|||
|
|
|||
|
Flip-flop a turns off! Now, con remembers a low pulse from module a, and
|
|||
|
so it sends only a high pulse to output.
|
|||
|
|
|||
|
Push the button a third time:
|
|||
|
|
|||
|
button -low-> broadcaster
|
|||
|
broadcaster -low-> a
|
|||
|
a -high-> inv
|
|||
|
a -high-> con
|
|||
|
inv -low-> b
|
|||
|
con -low-> output
|
|||
|
b -low-> con
|
|||
|
con -high-> output
|
|||
|
|
|||
|
This time, flip-flop a turns on, then flip-flop b turns off. However,
|
|||
|
before b can turn off, the pulse sent to con is handled first, so it
|
|||
|
briefly remembers all high pulses for its inputs and sends a low pulse to
|
|||
|
output. After that, flip-flop b turns off, which causes con to update its
|
|||
|
state and send a high pulse to output.
|
|||
|
|
|||
|
Finally, with a on and b off, push the button a fourth time:
|
|||
|
|
|||
|
button -low-> broadcaster
|
|||
|
broadcaster -low-> a
|
|||
|
a -low-> inv
|
|||
|
a -low-> con
|
|||
|
inv -high-> b
|
|||
|
con -high-> output
|
|||
|
|
|||
|
This completes the cycle: a turns off, causing con to remember only low
|
|||
|
pulses and restoring all modules to their original states.
|
|||
|
|
|||
|
To get the cables warmed up, the Elves have pushed the button 1000 times.
|
|||
|
How many pulses got sent as a result (including the pulses sent by the
|
|||
|
button itself)?
|
|||
|
|
|||
|
In the first example, the same thing happens every time the button is
|
|||
|
pushed: 8 low pulses and 4 high pulses are sent. So, after pushing the
|
|||
|
button 1000 times, 8000 low pulses and 4000 high pulses are sent.
|
|||
|
Multiplying these together gives 32000000.
|
|||
|
|
|||
|
In the second example, after pushing the button 1000 times, 4250 low
|
|||
|
pulses and 2750 high pulses are sent. Multiplying these together gives
|
|||
|
11687500.
|
|||
|
|
|||
|
Consult your module configuration; determine the number of low pulses and
|
|||
|
high pulses that would be sent after pushing the button 1000 times,
|
|||
|
waiting for all pulses to be fully handled after each push of the button.
|
|||
|
What do you get if you multiply the total number of low pulses sent by the
|
|||
|
total number of high pulses sent?
|
|||
|
|
|||
|
Your puzzle answer was 791120136.
|
|||
|
|
|||
|
--- Part Two ---
|
|||
|
|
|||
|
The final machine responsible for moving the sand down to Island Island
|
|||
|
has a module attached named rx. The machine turns on when a single low
|
|||
|
pulse is sent to rx.
|
|||
|
|
|||
|
Reset all modules to their default states. Waiting for all pulses to be
|
|||
|
fully handled after each button press, what is the fewest number of button
|
|||
|
presses required to deliver a single low pulse to the module named rx?
|
|||
|
|
|||
|
Your puzzle answer was 215252378794009.
|
|||
|
|
|||
|
Both parts of this puzzle are complete! They provide two gold stars: **
|
|||
|
|
|||
|
At this point, you should [16]return to your Advent calendar and try
|
|||
|
another puzzle.
|
|||
|
|
|||
|
If you still want to see it, you can [17]get your puzzle input.
|
|||
|
|
|||
|
You can also [Shareon [18]Twitter [19]Mastodon] this puzzle.
|
|||
|
|
|||
|
References
|
|||
|
|
|||
|
Visible links
|
|||
|
1. https://adventofcode.com/
|
|||
|
2. https://adventofcode.com/2023/about
|
|||
|
3. https://adventofcode.com/2023/events
|
|||
|
4. https://teespring.com/stores/advent-of-code
|
|||
|
5. https://adventofcode.com/2023/settings
|
|||
|
6. https://adventofcode.com/2023/auth/logout
|
|||
|
7. Advent of Code Supporter
|
|||
|
https://adventofcode.com/2023/support
|
|||
|
8. https://adventofcode.com/2023
|
|||
|
9. https://adventofcode.com/2023
|
|||
|
10. https://adventofcode.com/2023/support
|
|||
|
11. https://adventofcode.com/2023/sponsors
|
|||
|
12. https://adventofcode.com/2023/leaderboard
|
|||
|
13. https://adventofcode.com/2023/stats
|
|||
|
14. https://adventofcode.com/2023/sponsors
|
|||
|
15. https://www.boot.dev/?promo=ADVENTOFCODE
|
|||
|
16. https://adventofcode.com/2023
|
|||
|
17. https://adventofcode.com/2023/day/20/input
|
|||
|
18. https://twitter.com/intent/tweet?text=I%27ve+completed+%22Pulse+Propagation%22+%2D+Day+20+%2D+Advent+of+Code+2023&url=https%3A%2F%2Fadventofcode%2Ecom%2F2023%2Fday%2F20&related=ericwastl&hashtags=AdventOfCode
|
|||
|
19. javascript:void(0);
|