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 our module and speeding through the solar system. Unfortunately, we seem to have picked up a distress beacon! What is it saying? We must update our IntCode interpreter to find out!
Part 1 seems simple enough: Add big number support and a new relative parameter addressing system.
And after whacking our heads against the wall on why relative mode wasn't working the way we thought it should for too long, Part 2 is "merely" the same as part 1, but potentially very slow. If you weren't careful, your solution might be running for a long time.
Ongoing Meta
Dev.to List of Leaderboards
-
120635-5c140b9a
- provided by Linda Thompson
If you were part of Ryan Palo's leaderboard last year, you're still a member of that!
If you want me to add your leaderboard code to this page, reply to one of these posts and/or send me a DM containing your code and any theming or notes you’d like me to add. (You can find your private leaderboard code on your "Private Leaderboard" page.)
I'll edit in any leaderboards that people want to post, along with any description for the kinds of people you want to have on it. (My leaderboard is being used as my office's leaderboard.) And if I get something wrong, please call me out or message me and I’ll fix it ASAP.
There's no limit to the number of leaderboards you can join, so there's no problem belonging to a "Beginner" and a language specific one if you want.
Neat Statistics
I'm planning on adding some statistics, but other than "what languages did we see yesterday" does anyone have any ideas?
Languages Seen On Day 08
- javascript x 4
- kotlin x 2
- python x 2
- PHP
- clojure
- perl
- swift
Completion Stats
By applying a best-fit descending power trend-line to the 1 and 2 star columns on the stats page, my estimates predict:
1 star on day. 25: 6358 people
2 stars on day 25: 420 people. Nice
If you're still going, take heart in that you are in a rapidly dwindling pool of people.
Doing other questionable statistics gives me: 415/6248
Top comments (23)
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!