I was afraid of this. Another intcode problem >.<
it feels like these Intcode problems favour imperative languages which can just bash at a mutable Turing machine tape 😕
Perhaps. But you can always find ways to express it more neatly in Lisp. 🙂
Seems likely to be the last, though, because we've now been told we have 'a complete Intcode computer' ...
Unless we start making more chains of the things
I wonder when there'll be a lambda calculus based puzzle 🔥
It is neat to see which bits of existing instructions I needed to make more robust
My memory access functions got abstracted away from the vector representation hard in this problem
Yeah, it was a really neat testament to Clojure's Associative abstraction that I could just substitute my vector representation of the tape with a hash-map, and pretty much zero refactoring
I just ended up extending the vector if setting beyond range
But if it was truly sparse memory access, I'd definitely have to push it to either a map or a bunch of map-indexed blocks (0-999, 3000-3999, etc.)
But I reaaaally didn't want to go full B-Tree 😛
And it seemed to work fine
All I did was v -> (into {} (map-indexed vector v))
, solved a NPE by giving get
a default value, and everything else automatically worked, it was quite magical
much longer run time?
Shouldn't be, since you're only modifying one entry at a time; should be mostly reused per each tick
Hmm. The visualization's getting to the point where it's minimally useful, I suspect. And the size of the vector's making re-rendering every cell each frame rather prohibitive.
argh , reading opcode 9 adjusts the base
http://quil.info/sketches/show/a86e31254e4e2b7275aa6363279390b7d369d44b0dfd5d6da33f8039e9163fb9 - Color only, since the memory size is far larger and it starts slowing down frames - and don't have the time to implement a 'dirty cells only' routine
hmm seems i keep failong the input test. opcode 203 this should store the input relative to base right?
I'm having the same problem, with the puzzle input outputting 203. I've tried storing the input at many different ways, but no luck
Thanks! After looking at your message and my code a few hundred times I finally got it working [=
Funny, I'm stuck at the same point.
i.e. if base is 10
and the instruction is 203,-5
store the input value in index 5
It is a postition, I messed this up by trying to store at the index of the value at index 5.
seems very likely
so a target has also rel to base addressing
If the quine works for you (with it's 204
), maybe try another simple example?
109,12,203,-5,204,-5,99
Simply appends the given input and outputs it.
so you take the immediate value and add it to base for 203
yep thats it
same change is needed for all storing ops
👍 Nice, I'm not sure how to think about this. Up until today, I was treating outputs as a special case and always using the immediate mode.
Today, after refactoring, I realized I could handle my args as always pointing to a position and just pointing to the argument position in the case of immediate mode.
Makes it so I can handle all the args generally, and operands (as opposed to outputs) are just fed through an additional (nth)
right before they're needed, but for an output, they're already representing the positional value.
yes! part 1 done
the target adress behavior has been a source of pain in all intcode puzzles
part 2 is trivial after part 1
Yeah, I wonder if it's even possible to finish part 1 and not be able to complete part 2.
😂 I ran to work after completing part 1. I couldn’t complete part 2 so far 😂
I guess the tests in part 1 aren't adequate then.
I meant that I literally saw the message about getting the star and left without even reading part 2 😉 I did that on my way and will have to wait for tonight to get back to my code
Ahh, that makes sense. In this case at least, it shouldn't be a lot of work for you to finish part 2.
😁
sounds like using different input and go get it… a shame not to have done it directly. 🤷:skin-tone-2: but I was already late for real life 😉 And I have seen problems before that also seemed to only need a different input but then created out of memory errors and such… (see e.g. 2016, day 16)
I don’t understand what makes day 7 p2 halt
why not feedback forever? Or do the outputs start to decrease?
I had the same problem
try this thread, if you want the same explanation I got: https://clojurians.slack.com/archives/C0GLTDB2T/p1575701095380500
got it, thanks
:thumbsup::skin-tone-2: you’re welcome. This made a solid knot in my brain 😂
feels like the job - spend more time trying to understand requirements than writing code
😂
It happened the same to me, I was forgeting to implement mode 2 for write arguments of opcodes 1 2 3 7 8
Got the same problem. :D @tws Is it ok now ?
ya’ll
clojure is so great
we it said we needed non-contiguous memory
instead of a vector for state, you can pass in a map
done
(I was using subvec
, so I did have to change to map over a range. But everything else Just Worked™.)
How did accessing elements not in the map just work and give 0?
get/get-in allow for a default value if an entry in a map doesn’t get found (see <https://clojuredocs.org/clojure.core/get-in> for reference)
I switched from vector to map and indeed I had to add a default 0 to all direct map access. I was just curious if I missed something like a default non existing value
In the Reddit thread, he said it should be a freebie, but part 2 might find some wrinkles in your implementation.
No, but it was trivial. I shadowed get
in my let binding.
https://github.com/potetm/advent-of-code/blob/master/src/advent_2019/day_5.clj#L20
Gotta catch up with all of you, here’s my day 8 https://gist.github.com/roman01la/7e505fa83e74b4730d74f096f6172fff
@potetm I cheated -- I still passed in a vector, but did a (into [] (concat program (take 999 (cycle 0))))
and just kept increasing the amount of 0s I was adding to the "memory" vector until it passed. I did this because I'm lazy and I hate the vm problems in AOC.
so "memory starting at 0" is not a looping indexes around, zzz
I just assumed it was gonna blow out any arbitrary pre-fill
I tried wrap first: (- idx (count mem)), but then just moved on with my life :kappa:
This has been painful even on Day 5, but destinations are always to be treated as values!
when all the amplifiers have halted the circuit is halted?
The broken test outputs from the BOOST program were super helpful to narrow things down.
No kidding.
FINALLY have this done. All I will say, is that part 2 is trivial once you have part 1.
yepp
My day 9: https://github.com/chrisblom/advent-of-code/blob/master/src/adventofcode/2019/intcode.clj#L80 I also forgot to set the mode for the write parameter, too bad the tests did not detect it.
same problem with relative writes for me - Eric could have mentioned that in the description
I assumed that because mode 1 doesn't exist for writing, only mode 0 does - but that's not the case
defensive coding (checking that the mode is well known in the code for set
) would have caught this
it's interesting - type checks or unit tests wouldn't really have helped here, although a simple (asset (= mode 0))
would have
Yeah, I had to run back to day 5 to check the wording of how output addresses are handled; he didn't say 'they are always positional mode', but rather 'they are never immediate mode'
My day 9, if anyone is curious in a Typescript solution: https://github.com/pesterhazy/advent2019/blob/master/typescript/src/puzzle09.ts
Modern Javascript shines here, with bigints and generators
(By choosing JS/Typescript I'm getting out of my comfort zone deliberately)
You could say it's a trap 🙂
Here's my solution: https://github.com/pastafari/adventofcode/blob/master/advent-2019/src/advent_2019/sunny_with_a_chance_of_asteroids.clj
haven’t tried yet, day job. I think it’s more about blocking when you’re expecting input, writing out current state, then resuming when you have some. I’m not going to do channels, I think it should work.
but honestly, I missed that from the requirements wholly
You're on the right way, but be careful to meaning you put behind "blocking". For the requirements, in my first (and probably second and third ^^) read, I miss this sentence. > If the amplifier has not yet received an input signal, it waits until one arrives.
Ah smart
Thanks
With help from the hints here (thanks) about read and write mode I managed to finish: https://github.com/transducer/adventofcode/blob/master/src/adventofcode/2019/day9.clj Could be shortened if numbers could be turned into IFns that look themselves up in a map, but I read that that’s not possible in Clojure (but that it is in cljs)
Visualisation from reddit yesterday: https://preview.redd.it/d2xityozj8341.gif?width=904&format=mp4&s=c97ef3e9af23ae0ed5b6a962322c59ef4c41477a