Day 23: Category Six
by Simon Berger
Links:
After yesterday’s theory based puzzle I couldn’t be happier to go back to something like this. It isn’t a springcode problem like I expected, but I’m totally down for multiple intcode computers communicating with each other.
What’s different from previous intcode problems is that this time you can’t just let the interpreter run until it halts or requires input because there are multiple computers running in parallel. To simulate them running in parallel I’m running the computers one instruction at a time. For each “step” each of the 50 computers runs exactly one instruction and the packets are distributed afterwards. It’s important when a computer sends a message that the receiving computer only receives the message in the next step. If we let a computer receive a message as soon as its sent then that implies that the receiver ran after the sender which means they’re not running in parallel.
I know this sounds like this is an issue I ran into myself and had a hard time debugging, but surprisingly, I didn’t. Thinking about it the first time did give me a brief moment of confusion though.
My intcode interpreter was already using input and output buffers so sending and receiving message wasn’t a problem. The only special case is the “no messages” input (-1). When a computer “steps” and the underlying intcode interpreter reaches an input instruction with an empty input buffer, that means means that the incoming message queue is empty. In that case, -1 is added to the input buffer and the intcode interpreter runs the instruction again.
I kind of wish the puzzle had already introduced the NAT in the first part. The first part basically asks you to get the first message that is sent to the NAT, so I don’t understand why it wasn’t phrased that way. Because I didn’t know about the NAT I used a lot of open-ended code to make it easier to adapt to the second part. Maybe that was exactly the point of omitting it though, who knows.
For the second part I initially wanted to write a new struct for the NAT. I would’ve used a “ReceivePacket” trait which is implemented by both computers and the NAT to make things nice and clean. But because the NAT needs to “monitor” traffic to detect when it becomes idle and it also determines when to stop, I decided to merge it in the already existing “Network” struct.
The network is “idle” when all computers have sent -1 to the underlying intcode computer and no packets are being sent. All that’s left is to remember the previous y value sent by the NAT and compare it to the current one. Once they’re equal we’ve found our solution.
Now that we most likely only have one intcode problem left I’m wondering what that last one will be. On the one hand I’m still hoping that we’ll see springcode again but after today, I wouldn’t be surprised if it’s a continuation of this network. After all, we don’t know what the messages being sent are. It’s suspicious that each message has an x and y value but we only care about the y value. Maybe it’ll be a drawing where the x and y values are points on the canvas? We’ll see.
tags: intcodeOverview
Previous day Next day