Oh no, IntCodes! (I'm starting to see a pattern here...)
Day 9 - The Problem
After an easy decryption of an image file, we're back in o...
For further actions, you may consider blocking this person and/or reporting abuse
So, we're going to work with Intcodes every other day? 😩
The worst part is that, since we're reserving two digit for the opcodes, I expect we're going to work with them again in the future (even though it says "You now have a complete Intcode computer.")
Moreover, the problem forgot to mention that when we write back to the memory, it could be done in relative mode too and not just position mode. Thanks 🤦♂️
But anyway... JavaScript with generators blah blah. I lost quite some time trying to understand why my solution didn't work... Until I realized I was passing the input values incorrectly 😵 I have none but myself to blame there...
Only new thing: the use of JavaScript's
BigInt
. Hooray for ES2020!Solution for both parts:
Running times:
Hardware: MacBook Pro mid-2015
As usual, my text and input can be found on my repo.
BTW, I'm dead last in the leaderboards among those who completed all 9 days 😂 Jon, you're ahead of me without today!
this burned me, i sat there for 30 minutes trying to figure out what i was doing wrong
I believe the two digits are just there because of opcode 99 :)
And that would make ten opcodes so far, right.
Well, let's hope we won't have to implement more! 😄
After all we already have basic arithmetic, I/O, conditional jumps, comparisons and pointer manipulation... What else do we need for a basic processor?
We're in uncharted waters! I think this is first year we've had so much refactoring/reuse work to do. (Definitely the earliest)
It's been pretty frustrating going, but getting things to work has been satisfying as heck.
Hi, a (very wordy) Python solution using a generator function.
Getting output is done by running:
then...
Part 1
or Part 2:
"""
Hi,
now i am learning python
i also wrote a program in very basic
but i did not get the answer
can u give me any hint
"""
import numpy as np
f = open("input9","r") # file opening
code = f.read() + ',0' * 1000 # for reading files with commas(,) as list
nList = code.split(',')
f.close() # file closing
print(nList)
for i in range(0, len(nList)): # converting elements of List(strings) into integers
nList[i] = int(nList[i])
print(len(nList))
def get_digit(number, n):
return number // 10**n % 10
def intcode(nList,in1):
List = nList.copy()
for i,each in enumerate(nList):
List[i] = int(each)
i = 0
rb = 0
boost_program = intcode(nList,1)
print(boost_program)
print(intcode(boost_program,1))[1]
I'll be posting my other attempts to: github.com/devChad/advent_of_code
JS Solution w/ generators again
I like being able to "plug in" the IO implementation at runtime with the yields, it's almost like algebraic effects in JS
Dope! Ive started doing this but it was taking me too long, checkout my solutions at github.com/LeonFedotov/advent-of-code
I've been sending input and read output "manually", but it worked well enough for day 7. Interestingly, I learned something about ruby today: arrays are essentially unbounded! so i didn't have worry about the memory issue, I could just read/write to where in the array I wanted and if the array was too short, I'd just read out a
nil
instead of getting some form ofIndexOutOfBoundsError
or something.I made this comment somewhere else in the thread, but the fact that opcode
09
could also work in relative mode, (and that we could write to addresses in relative mode as well) threw me off, I spent way too long trying to track that bug down.Well that was tough! The new requirements revealed a few deficiencies with my IntCode emulator. My addressing modes were a mess for writes, but somehow made it this far anyway. The need to expand the memory on demand meant a substantial refactor. I also had to use a nonstandard (but widely supported)
__int128
data type to support the big numbers required.Printing large numbers is also lacking support in the C standard library. I had to cut a couple of corners...
As part of my debugging I had it trace the execution using made-up assembly language:
One advantage of using C is speed though. We were warned it might take time to run but the tests and both parts of my implementation run in 84 milliseconds!
Full code here. I've enjoyed my return to C programming but I'm quietly hoping for something using a high-level language tomorrow!
Today's addition was simple enough. For safe access to "not yet allocated" memory, I created 2 new helper functions:
And after changing the instruction type from int to long (which is the default number type in clojure anyway), I could just add the new stuff to my existing framework:
As always, here's the whole code: github.com/jkoenig134/AdventOfCode...
Had a rough time hunting down some issues that caused all of the available test cases to pass but failed my puzzle input. Turns out I should have been using "x % 10" to get the one's digit, not "x % 3" like I had.
Also, I feel like the specification for how opcode 3 (read input) works with this new relative parameter mode wasn't made super clear. But it worked out in the end. Here's my rust solution:
And my Intcode Interpreter:
My big deal was making the Intcode computer fully backwards compatible with Day 5 and 7 as well as making it run for Day 9. (I haven't tried it with Day 2, though for some reason there's a part of my brain that thinks that is perhaps irreconcilable with that day).
I felt like the directions to this one were incredibly unclear. Should the program be able to write in the original instruction space or not? "Memory beyond the initial program starts with the value 0 and can be read or written like any other memory. (It is invalid to try to access memory at a negative address, though.)" What does "beyond" mean here? How do you differentiate between "beyond" memory and "any other memory," particularly if you can't "access memory at a negative space"? It was also unclear that the "beyond" memory was actually initialized with zeros. (I originally assumed that the program wouldn't attempt to access uninitialized space, but that ended up being proved wrong almost immediately.)
Still, this implementation served me pretty well:
And the driver program for Day 9:
woof, here's my new Kotlin intcode parser, as the day's specific code is now as simple as loading the file, splitting it, and running it.
Key rewrite pieces:
copy
FUNCTION WHEN PRESERVING IMMUTABILITY!I was unpleasantly tired yesterday so failed to complete in time, leaving me behind on day 10, too. But at least I got day 9 done.
There's a lot of code, so I've left it in a gist:
Hi 😙
My solutions are here: github.com/LeonFedotov/advent-of-code
I really enjoy these IntCode challenges, especially when you have a problem in your code and find that the program from the problem statement is showing you where it's wrong 🤩
OH MY GOD! Again opcode computer. I tried many time but couldn't create the perfect computer (with swift). Might take a break and come back with FRESH, from Scratch opcode computer and post it later.
It took some time but finally solved with Swift.
Code can be found here: github.com/rizwankce/AdventOfCode/...