Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-12-09

Channels

#adventofcode
<
2019-12-09
>
Mario C.05:12:48

I was afraid of this. Another intcode problem >.<

😂 4
yuhan05:12:56

it feels like these Intcode problems favour imperative languages which can just bash at a mutable Turing machine tape 😕

fellshard05:12:05

Perhaps. But you can always find ways to express it more neatly in Lisp. 🙂

fellshard05:12:28

Seems likely to be the last, though, because we've now been told we have 'a complete Intcode computer' ...

fellshard05:12:46

Unless we start making more chains of the things

yuhan05:12:06

I wonder when there'll be a lambda calculus based puzzle 🔥

fellshard05:12:17

It is neat to see which bits of existing instructions I needed to make more robust

fellshard05:12:52

My memory access functions got abstracted away from the vector representation hard in this problem

yuhan06:12:35

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

👍 4
fellshard06:12:10

I just ended up extending the vector if setting beyond range

fellshard06:12:03

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.)

fellshard06:12:12

But I reaaaally didn't want to go full B-Tree 😛

fellshard06:12:16

And it seemed to work fine

yuhan06:12:15

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

mpcjanssen06:12:54

much longer run time?

fellshard06:12:34

Shouldn't be, since you're only modifying one entry at a time; should be mostly reused per each tick

fellshard07:12:56

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.

mpcjanssen07:12:33

argh , reading opcode 9 adjusts the base

🙂 4
fellshard08:12:28

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

mpcjanssen09:12:32

hmm seems i keep failong the input test. opcode 203 this should store the input relative to base right?

gbouvier09:12:28

i.e. if base is 10 and the instruction is 203,-5 store the input value in index 5

gbouvier09:12:57

It is a postition, I messed this up by trying to store at the index of the value at index 5.

pastafari17:12:03

This has been painful even on Day 5, but destinations are always to be treated as values!

herald09:12:31

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

Average-user14:12:55

It happened the same to me, I was forgeting to implement mode 2 for write arguments of opcodes 1 2 3 7 8

herald20:12:41

Thanks! After looking at your message and my code a few hundred times I finally got it working [=

rjray09:12:55

Funny, I'm stuck at the same point.

mpcjanssen09:12:42

seems very likely

mpcjanssen09:12:58

so a target has also rel to base addressing

gbouvier09:12:21

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.

mpcjanssen09:12:39

so you take the immediate value and add it to base for 203

mpcjanssen09:12:34

yep thats it

mpcjanssen09:12:25

same change is needed for all storing ops

gbouvier10:12:56

👍 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.

mpcjanssen10:12:49

yes! part 1 done

🎉 4
mpcjanssen10:12:15

the target adress behavior has been a source of pain in all intcode puzzles

mpcjanssen10:12:57

part 2 is trivial after part 1

gbouvier10:12:44

Yeah, I wonder if it's even possible to finish part 1 and not be able to complete part 2.

meikemertsch10:12:27

😂 I ran to work after completing part 1. I couldn’t complete part 2 so far 😂

gbouvier10:12:59

I guess the tests in part 1 aren't adequate then.

meikemertsch10:12:44

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

gbouvier10:12:20

Ahh, that makes sense. In this case at least, it shouldn't be a lot of work for you to finish part 2.

meikemertsch10:12:32

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)

fellshard16:12:58

In the Reddit thread, he said it should be a freebie, but part 2 might find some wrinkles in your implementation.

tschady13:12:35

I don’t understand what makes day 7 p2 halt

meikemertsch13:12:53

I had the same problem

pastafari18:12:16

when all the amplifiers have halted the circuit is halted?

tschady13:12:57

why not feedback forever? Or do the outputs start to decrease?

meikemertsch13:12:34

try this thread, if you want the same explanation I got: https://clojurians.slack.com/archives/C0GLTDB2T/p1575701095380500

tschady13:12:20

got it, thanks

meikemertsch13:12:16

:thumbsup::skin-tone-2: you’re welcome. This made a solid knot in my brain 😂

tschady13:12:50

feels like the job - spend more time trying to understand requirements than writing code

Charles Fourdrignier14:12:24

Got the same problem. :D @U1Z392WMQ Is it ok now ?

tschady21:12:59

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.

tschady21:12:19

but honestly, I missed that from the requirements wholly

Charles Fourdrignier21:12:58

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.

potetm15:12:05

clojure is so great

potetm15:12:30

we it said we needed non-contiguous memory

potetm15:12:55

instead of a vector for state, you can pass in a map

potetm15:12:48

(I was using subvec, so I did have to change to map over a range. But everything else Just Worked™.)

mpcjanssen15:12:19

How did accessing elements not in the map just work and give 0?

meikemertsch16:12:48

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)

💯 4
mpcjanssen16:12:46

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

potetm16:12:10

No, but it was trivial. I shadowed get in my let binding.

James Adam16:12:36

@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.

misha17:12:59

so "memory starting at 0" is not a looping indexes around, zzz

potetm17:12:00

I just assumed it was gonna blow out any arbitrary pre-fill

misha17:12:07

I tried wrap first: (- idx (count mem)), but then just moved on with my life kappa

pastafari19:12:46

The broken test outputs from the BOOST program were super helpful to narrow things down.

☝️ 4
rjray19:12:37

No kidding.

rjray19:12:55

FINALLY have this done. All I will say, is that part 2 is trivial once you have part 1.

chrisblom20:12:54

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.

pesterhazy20:12:13

same problem with relative writes for me - Eric could have mentioned that in the description

pesterhazy20:12:47

I assumed that because mode 1 doesn't exist for writing, only mode 0 does - but that's not the case

pesterhazy20:12:21

defensive coding (checking that the mode is well known in the code for set) would have caught this

pesterhazy20:12:30

it's interesting - type checks or unit tests wouldn't really have helped here, although a simple (asset (= mode 0)) would have

fellshard20:12:32

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'

pesterhazy20:12:35

You could say it's a trap 🙂

pesterhazy20:12:30

Modern Javascript shines here, with bigints and generators

pesterhazy20:12:57

(By choosing JS/Typescript I'm getting out of my comfort zone deliberately)

erwinrooijakkers23:12:32

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)

misha04:12:51

(map-indexed (fn [i v] [i v])) 

(map-indexed vector)

🙏 4