Fork me on GitHub

typos and misreading just murdered me on part 1 of day 4


> 111122 meets the criteria (even though 1 is repeated more than twice, it still contains a double 22). i can't fathom how this meets the rule? "the two adjacent matching digits are not part of a larger group of matching digits". Aren't the two adjacent 1s that start the number part of a larger group of 4 matching 1s?


There just has to be a pair in the number that is not part of a larger group


It's 'exists', not 'all'


The 1s do not satisfy the condition, but the pair of 2s do


The two adjacent 1s are part of a larger group of 1s


That through me off as well for a good while

dpsutton04:12:30 did it in core.logic. would love people more familiar with it to critique. i know there has to be some more clever bits

parrot 4

Well, the new one is going to take some study… 😉


I’m really digging the build-a-cpu aspect of it


I guess I reached the limit of doable on phone today.


whoever complained about puzzle description yesterday, how do you like it now? lol


especially the compare it to the value 8 bit. wtf is that about?


I can't find it in the text... (in part 1)


Those are sample programs, as he notes. You can try running them / stepping through them to get the behaviour he says it will have (in this case, comparing numbers to 8 in various ways). Use them as test cases for your implementation before trying to run your full program.


that is some unnecessary complication/indirection for test cases, which is useless, unless your implementation fits. instead of just "this (much shorter) input returns x", which is implementation agnostic, although more blackboxy


Sure, he could have made some shorter. You can always test each instruction in isolation if you want. He's giving slightly larger test cases that make for 'full programs', though, from input to output; call them integration tests.


I didn't even read the tests lol, just added the 4 new instructions


there was too much text today 😄


You ain't seen nothin' until you've solved 2018-15. (That problem gained quite a bit of infamy for being very fiddly to solve, and taking a whole bunch of space to thoroughly explain to boot)


I think I just printed output to figure it out, then


yenda, i read tests when description is unclear, so tests screwed me over even more today opieop


and shouldn't this Parameters that an instruction writes to will never be in immediate mode. be Parameters that an instruction writes to will never be in position mode.?


Basically, ignore the mode for that parameter - always treat the parameter's value as the address to output to.


the thing is, my code works only for opposite: when it is literal v :

1 (recur idx* output (assoc state c (+ A B)))
instead of
1 (recur idx* output (assoc state (state c) (+ A B)))


I lost like 40 minutes chasing this


Correct, that's position mode by definition.


position mode = 'the value in the cell is an address' (whether for input or output) immediate mode = 'the value in the cell is a concrete value' (for input only) You're assuming 'position mode' also means 'get the value from the addressed cell and use that as the address to output to', which is stretching the definition of 'position mode' one step too far. The mode only tells you how the parameter's value is to be interpreted: the action you take with the parameter depends entirely on the command's context. For positional inputs, you read from the address. For positional outputs, you write to the address.


all I can say – I don't interpret the description as unambiguously as you do.


(given context, which is load of text from both day 5 and day 2)


positional: "interpret v as a pointer" intermediate: "interpret v as a value"


you can only write to a pointer, a mutable container; you cannot conceptually write to an immutable value


It should be in position mode. It writes to the address. So it's ok.


yes, but the value of address to write to is always in immediate mode (for my input anyway). maybe I am confusing myself by thinking about it as: in immediate: (f x) => (f x) in position: (f x) => (f (get state x)) but in my solution, I never do (update state (get state x) ...), instead all of instruction do: (update state x ...) , which is pretty immediate to me


(where state is a mutable puzzle-input vector)


from this perspective, yes, I have to agree.


I don't get this sentence: Non-zero outputs mean that a function is not working correctly; check the instructions that were run before the output instruction to see which one failed.


What the 'check' means here?


And how to make to get 0's for all test outputs?


Similar to what he made for the Synacor challenge


tl;dr the program's first section checks for specific bugs in your implementation. For each of those tests, if it passes, it spits out a 0 in the output.


So a successful run of the first part should be 0 0 0 0 0 0 ... 0 0 <diagnostic code>


If something did go wrong in your implementation, you could use the output to help you pin down where it's going sideways


But it'd take some doing


Aaah... I understood this checks provided code not my implementation. Clear now.

Jett Durham07:12:19

Yeah, this confused me too at first. Made me think we might have to modify the instructions in our code! 😅 To me, it seems unlikely that you’d actually have a solution that yields non-zero intermediate results and actually executes all the way to the terminating opcode.


That part wasn't the clearest stated. I only caught on because I've seen him use it before. 🙂


Today was smooth sailing, mostly reading comprehension (again in Typescript:


Just soldiered through on phone. Day 5 done


Tricky part was the targets are never in immediate mode part


Again the key was to make small fns


On phone? I can’t even..


I was planning to stop today


But with small enough steps it was doable


Oof. That was rough. Completed Day 5, but my code is too ugly to share. My “program step” function consisted mostly of “case opcode” statements to update the program and calculate the next instruction offset. I think if I refactored it, I’d have a single function per opcode that would return the altered program and next program counter.


If we add many more instructions to this VM, though, I'll probably move the dispatch to a vector.


I pass around a state map with mem, input, output, ip and halted keys.

☝️ 4

So the opcode handlers can update the ip.

👍 8

Already made that choice on day2 and it worked well today


after some cleanup it actually became quite readable [=

👍 4

Nice! I like the use of reduce and the (format "%04d" code) to unify the calculation of the positional vs. immediate values. I used a recursive strategy:


Thanks. Apart from those two differences (and you keeping track of input) our solutions are pretty similar!


The drop off in completed answers for today is huge

James Adam16:12:14

Yea, I looked at the problem description early this morning and decided I'd tackle it after work tonight 🙂

Mario C.16:12:38

Day 5 description wasn't bad. I had to rewrite the intcode program though. Didn't like my day 2 solution. Day 5 part 2 was easy so long as what you wrote for part 1 was 'extendable' for a lack of a better term

Mario C.16:12:57

Most functions were repeated code. So I could have probably had a wrapper that passed in the operation function while keeping the rest the same.

Mario C.16:12:35

Day5 problem reminds me of my class on automata in college. Where you create DFA's and NFA's and there was the one where you have a tape. and you can move left or right


Yeah, mostly because the data here is sitting in the same space as the instructions, and under theory he could build programs that mutate their own code on the fly.

Mario C.16:12:16

turing machine

Roman Liutikov20:12:27

The part about always treating write location as a pointer instead of a value could be indeed confusing from implementation standpoint. Here in writable instructions 1, 2, 3, 7 and 8 I’m treating location as a value (“immediate” mode or 1) because it allows to keep parameter interpretation code simpler

Roman Liutikov20:12:19

my understanding is that you want to interpret write location as a value instead of a pointer, because the value is used to assoc something onto memory object, otherwise you’d first have to retrieve the value of the pointer and then use that value to assoc onto the memory, which is incorrect


Yeah, your first instinct is to use the same logic as you would for position-mode input, but that's inevitably not right. I did the same at first, then realized I needed to just excise output parameters entirely and not pass them through the mode filter.


Can someone help me refactor this function from day 1 into using reduce or something more idiomatic? I still can't break myself off of immediately going to loop/recur


(defn total-fuel-mass [mass]                                                                                         
  (loop [remaining mass                                                                                              
         total 0]                                                                                                    
    (let [mass (fuel-mass remaining)]                                                                                
      (if (pos? mass)                                                                                                
        (recur mass (+ total mass))                                                                                  


I'd recommend looking into iterate. When there isn't an explicit sequence to reduce over, and when creating one doesn't make sense either, iterate gives similar mechanics. I use it a lot in AoC, where many problems are run until you reach a fixed point.


Will do! Thanks


I think I'm close already! But I'm missing something crucial because I'm getting an answer that is too high.


(defn total-fuel-mass [mass]                                                                                         
   (reduce + (take-while pos? (iterate fuel-mass mass)))) 


formatting looks funky here from my copy and paste but it's lined up correctly in my editor.


skip the first element


(defn total-fuel
  "Return the fuel units required to launch a module of given `mass`,
  including the mass of the fuel carried."
  (->> mass
       (iterate mass->fuel)
       (take-while pos?)
       (reduce +)))


first run through iterate is the mass of the ship, which you don’t need


ahhh! I should have spotted that when I was exploring it in the repl.


thanks folks!


(Funny side-note: I mis-read the bit about only being allowed one private leaderboard, to mean that I could only BE on one private leaderboard at a time. So I hadn't joined the channel's leaderboard as I was already on a private one for fellow AoC enthusiasts within my company. Just joined, and thrilled to see I'm in 3rd place!)