Did you get your IntCode machine just right on Day 5? Well, too bad, it was wrong.
Day 7 - The Problem
Looks like we need more power. A...
For further actions, you may consider blocking this person and/or reporting abuse
Hi,
Someone please help me understand part 2 of day 7
I am trying to get the answer given in first example of part two.
The input is
3,26,1001,26,-4,26,3,27,1002,27,2,27,1,27,26,
27,4,27,1001,28,-1,28,1005,28,6,99,0,0,5
For sequence 9,8,7,6,5
First input I gave was 9 as phase setting
Then gave 0 at the second occurrence of opcode 3
The program proceeds but it encounters opcode 5 at position 23 and resets my address pointer to 6. At 6 again the opcode is 3. Now here I give 8(next phase setting) or previous output value? Also in this way my program is not reaching 99 and it kept running until i killed it.
Roughly I think:
So... when the first amp gets to its third or later input, it needs to wait until it receives an output from the last amp.
Once all amps reach 99, the answer is the last outputted value from the last amp.
Got the output. Its 3:30 AM and I can finally sleep now.
Hello...
Believe it or not, I'm still not getting how Part 2 works... I like the way you spelled things out in your post per the sample data. Enter 9, then enter 0, etc. Can you do something similar with the understanding you've gained here? I would truly appreciate it. Thanks.
My attempt:
In part 1, a sequence of 2 amps (A0,A1) will operate like so:
Part 2 is... complicated to diagram, but I will try (again with two amps, A5 and A6)
Obviously the prompt uses 5 amps, and your input code produces a larger number of outputs per amp than my example. But I think this is the minimal state diagram possible that shows off the difference.
Please feel free to ask clarifying questions!
Thanks for replying... I'm a new programmer, and I'm not sure why, but things still aren't making sense. Let me tell you what I'm doing. First of all, Part 1 works fine for me. This is what I do for Part 2 (sample 1).
Sample one is:
Max thruster signal 139629729 (from phase setting sequence 9,8,7,6,5):
3,26,1001,26,-4,26,3,27,1002,27,2,27,1,27,26,
27,4,27,1001,28,-1,28,1005,28,6,99,0,0,5
So...
I start the program, I guess it would be on Amp A. It asks for input, and I give it 9 (from the phase setting sequence above). Then it asks for a second input, and I give it 0 (from the instructions in Part 2). At that point I get an output of 5 and the program stops... Here I have a few questions... 1) should the program have stopped? 2) When I start up the program on Amp B do I start with fresh data (above), or do I use the updated data (I'm using a hash table).
So, then, I guess I start Amp B; it asks for an input. I give it 8, the second number in the phase setting sequence. It asks for another input, and I give it a 5 (from the output above). At that point the program stops and outputs 14. So, at this point I have two amps that have already stopped. This goes on until I get to the fifth amp and I get an output there. But, Amp A has already stopped (it stopped right away). So, what do I do with the output I just got from the fifth amp? It's not the solution; it's a low number.
Hopefully, some of this makes sense. If I can't get the sample to work, I don't know how I'm going to get the puzzle data to work. Any replies would be very welcome.
The key to debugging what you have here is probably knowing why your program stopped.
In my initial version of the IntCode interpreter would explode when it tried to read input when there was none to give it.
Each Amp should "pause", but not stop when it needs input that isn't there.
Here's my part 2 solution in #haskell. I ended up needing to do some substantial refactoring from my previous solution that I'd used for day 5 as well as part 1. My original version attempting to go for performance by using mutable vectors to store the program state, ostensibly allowing for more performant seeks and writes to the program state. I started to extend this approach using IORefs to program state and some other clever trickery. Although I managed to get constant memory utilization, the performance was so bad the program never actually finished running.
After profiling didn't help enough, and I verified that there was nothing unsound about my algorithm, I decided to start from the ground up with the simplest solution and went back to a pure implementation using record updates to manage all of the changes to start, and manually sending IO between the amplifiers. Once again proving that when it comes to optimization I'm never as clever as I think I am, the compiler did it's job and took my naive implementation and gave me a version that finished in a couple hundred milliseconds.
My new version needs some refactoring still, both for readability and ergonomics during future challenges, but here is the version left on my disk from when I finally finished up at 5am:
Yoooo and I thought day 5 was annoying π«
Anyway... JavaScript. It has this nice generator thing that I basically never used professionally and very rarely by myself, and here I am using them twice here. But you know, they're quite good for stateful machines. (Which is also why I rarely use them - like many others, I prefer stateless approaches.)
This is the solution for the second part, as the first can run the first (except for the phase settings, where I just add 5 to the permutation's elements - see at the end).
Many parts are the same of day 5 of course. Sorry for the repetition.
See text, input and first part on my repo.
Horray, finally got part 2 solved!! happy dance Took FOREVER but I finally got it working. This will be the part 2 solution in JavaScript (part 1 was very similar, just slightly more simplified and didn't involve the objects I created for each amp).
Day 7 with swift
I did it all in sync, runs well enough nonetheless.
And here's the ever growing intcode computer: github.com/jkoenig134/AdventOfCode...
Part one was a piece of cake imo. Part two was a lot tougher.
I decided to go with javascript and use generators so I could easily suspend the amplifier program between inputs
Well, today was definitely fun. Continuing in Python from previous days, part one was fairly easy as the modifications to my existing Intcode computer were minimal and the task itself was fairly straight-forward, but part two was interesting.
For part two, I chose to rewrite my whole Intcode computer in dart, as that is the language I am most familiar with, and I'm happy I did so. I then gave each amplifier a StreamController as its output and the BroadcastStream of the previous amplifier's StreamController as its input and had them listen to each other in async. Probably not the easiest way to do it, but very fun and interesting to write.
Here's the code for part 2:
And the code for my dart Intcode Computer: gist.github.com/jakcharvat/818c477...
Here's my solution to part 1 minus the obscene overhaul to Day05. I spent too long futzing because my refactor wasn't as friendly as I had hoped, and there was a terrible bug in my permutation generator.
I'm now mulling whether I want to go full Coroutines for part 2...
Playing some Sunday night catch-up. My previous architecting bit me in the butt today. Had to re-think my "stdin/stdout" concepts. Converted them to vector buffers (should probably have used queues, but too lazy). Worked out pretty well. The key for me was adding in a new opcode (98, so far unused) to signify a halt waiting for input rather than a full program halt (99). Here's my (part 2) solution in Rust:
And, my Intcode Interpreter, for reference. I completed day 7 and 9 back to back, so there's some day 9 stuff in here that won't apply to this problem:
Well that was fun! My decision on day 2 to do the machine simulator in C continues to be both an advantage and a disadvantage. I'm enjoying flitting between the low-level pointer hacking and the high-level Prolog and Haskell solutions on other days.
Generating the permutations of the phase signals was the hardest bit today. The principle is a simple one - lock some digits, generate the permutations of the remaining, and recurse - but the details and corner cases in recursive C were a bit tricky.
Today's code runs both parts in 14 milliseconds!
Code at github.com/neilgall/adventofcode20...
Part 1: oh gods, so many for loops
(using basically the same intcode processor from day 5, except output is put into a variable instead of output to the console)
FINALLY got part 2 done. Had to mess around so much:
For some reason I can't get this to work with part 1, but I'm done worrying about it. π
Hey Jon, I was curious so I counted the languages used on day 6 for you π€
JavaScript Γ 4
Python Γ 2
Clojure Γ 1
Elixir Γ 1
Java Γ 1
Kotlin Γ 1
PHP Γ 1
Prolog Γ 1
Swift Γ 1
Awesome! Thanks! (Runs off to paste it in before I head to bed.)
That was hard, but here is my javascript walkthrough