On Day 19, we're headed back to the time machine's inner workings to play with more opcodes, and this time, our opcodes can fiddle with the program's instruction pointer!
It seemed like people mostly enjoyed the opcode challenge a few days ago (me included!), so this should be fun! Let's see your solutions.
Top comments (5)
For part1 I translated the code directly into C with a program in python:
The program was able to execute part1 but part2 was taking forever.
Then, after some failed ideas, I did a translator into "assembler" to study the code:
Then I studied the result:
And, after drawing a flowchart, I reassembled the code into:
The code sums all factors of the number stored in r1 !!!!
So, I factored 10551315 = 3*5*31*22691 and then sum all the divisors, as the program does.
For me it has been the best problem so far !!!
Part 1 was straight forward execution of the program.
For Part 2 I wasn't really sure how we were expected to solve, but I went with rewriting
asm
code intophp
and then looked for some possible optimization (early break from the loop in my case).opcodes.php
readFile.php
Part 2 of this one stumped me. I'm posting my code for part 1 here so I don't feel like a total failure, but I'm pretty bummed. I knew that you had to manually step through the instructions or convert them to some sort of higher level thing so that you could see what they were trying to do slowly and shortcut it. But, when I went through all that work and came up with a wrong answer, I looked here. I was thinking that we were summing all of the numbers up until a certain large number, but I was on the wrong track. After looking here at the answer, it seemed like cheating to finish a solution and get the star.
That's one point for you, Advent.
Anyways, here's my code for part 1 in Python:
JavaScript solution
I have a generic solution for Part 1 and a customized solution to my input for Part 2.
For Part 2, because it was taking forever, I decided to print the output and let it run for a few minutes and try to understand how the registers vary and why.
Then I followed the suggestions from @jmgimeno and analyzed my program to understand what should happen and what does the loop try to accomplish, and after some deep thoughts I concluded the register 0 is the sum of the dividers of the number in register 2! So I did that algorithm myself, manually.
I'm gonna omit reader.js which is the same as the other solutions and jump to the point:
19-common.js
19a.js
19b.js
Had our office Christmas lunch yesterday, with a few whiskies after so I didn't get Advent of Code finished by the end of the day!
Another machine simulation, building on Day 16's. While that allows for a more complex problem to be stated with fewer new details to outline, the problem is sufficiently different that I'm not sure how much code I'll be able to reuse.
We don't need to decipher the opcodes this time so I modelled them with an enum with attached names and execution functions.
The program itself is then just the Instruction Pointer register binding followed by a list of instructions.
And the parser is straightforward as ever:
Executing the program is just a loop running until the IP is out of range.
And part 1 is trivial:
Part 2
The second part was altogether a different problem. It runs for a very very long time, so you can't get the answer just by executing it. You have to decipher the code and work out what it's doing, then compute the result without actually running it. To cut a long story short, it initialises R3 with a huge number, then uses an extremely inefficient algorithm to find numbers which are factors of that number, adding the factors up as it goes.
In analysing the code I noted that the section which computes the very large number ends with the final instruction which is a jump to the main loop. I dropped that instruction and executed the program to get the big number.
Then I just reimplemented the algorithm in Kotlin with a more efficient method:
Full code