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);
|