Oof! The opcode from Day 2 is back with a vengeance.
Day 5 - The Problem
As we feared, the IntCode interpreter is back. It looks the ai...
For further actions, you may consider blocking this person and/or reporting abuse
OK, I'm really, really happy with how my refactoring on Day 2 came out. Even the addition of the input modes fit into place in nice, neat, decoupled chunks. And then it was a matter of letting my interpreter know about all of the new opcodes.
Note: I was very much not expecting my Day 2 setup to hold up this well. I think I got exceptionally lucky at how today's puzzle was structured. I'm fully expecting to run into a future IntCode puzzle in the coming days that blows my architecture out of the water and makes me start over.
My actual Day 5 module is not very impressive:
Here's where all the work gets done. Also, side note, as a happy fallout of how Rust's
stdin
handles itself, I can either enter values or pipe them in one-per-line, if future input gets more complicated :)I really enjoyed this one, actually. This is so much better than this time last year, when I was doing all kinds of input parsing tricks and tripping over log files. Give me straight-up integers in a comma-separated list any day!
I decided to make my code really readable and branched out into creating 2 Python enums and a class. It made writing the code feel like a snap, as I no longer had to wrap my brain around all kinds of numbers and could hang my head on descriptive operations.
A couple of the lines are unnecessary (like writing the repl function as well as there's a DRY violation with parameter interpretation)...but I really like the ternary if/then/else operator in Python. I'm used to Java's
print(x == 5 ? "yup" : "nope")
...print("yup" if x is 5 else "nope")
is far superior!Today's code is a lot uglier than yesterday's, but, oh well, it works. My JavaScript solution:
So, I actually reasonably enjoyed this day! :) It did take a good bit of deciphering exactly what I needed to make it do....the wording is so similar in the description of things! But once I got it, I knew what to do, which I honestly really like. lol :)
I did refactor a bit of what I did for day 2, so this currently contains all of my opcode options. Fingers crossed it will be easier to add onto when the next day comes to update it! (Though knowing AoC, chances of that might be slim lol)
I've got a decent bit of descriptive comments in here, to help make things easier for myself in the future. :) So hopefully that helps some folks out, too! Also, I really enjoy switch statements, and I like that they've worked for multiple days so far this year. lol
JavaScript solution
Jayyy-zus today was a long challenge 😫
I don't like it much when AoC does that, and when it back-reference problems from past days.
Anyway, here's my solution in JavaScript - just for part 2, as part 1 is basically embedded, you just have to change the input value to 1.
Not particularly proud of this, as the challenge itself was long but a bit bland. It's just parse, get instruction, execute, rinse and repeat. The only interesting part is the use of a generator function I guess...
As usual, I'm publishing my solutions on GitHub.
I built my original solution to this on top of my Day 2 solution, but was really unhappy about how that solution had turned out. So, I spent time over the weekend and into this morning building out a more clean solution around the Intcode Computer (knowing that it's going to likely be used more later).
The implementation is below (and also accessible here), along with the new execution calls for Day 2:
Initial kotlin solution (I'm going to clean this up a LOT, but in the interest of sharing what I learn, I promise not to pave this post over.)
Ok, as promised, here's the code I wanted to write, but I was halfway done before I saw it, and I wanted the answer so bad I didn't give myself the time to rewrite.
EDIT 2: Oops, all monads.
Definitely can say this implementation has a lot of
class
. 🤣Yeah, I wish there was a more elegant way of doing discriminated unions in Kotlin. I'm used to the lightweight kinds/types of Haskell. Arrow-KT lets you do basic stuff pretty nicely, but it gets ugly the more you try to be full functional style only.
I'm also disappointed in the type erasure.
I didn't enjoy this, it ate my entire evening, and I'm sad that it looks like I'm going to have to come back to it on future days. I've tried to clean it up so it's less of a nightmare to return to, but...
I didn't reuse my code from day 2, instead I wrote a new one in Racket. I feel that the choice of the language was right, but I made a lot of mistakes and the task itself did not help with any example inputs. Finally I made it. It's not as bad as I feared, but could be better:
EDIT: Ugh, what is with this code highlighting? :/
I wrote lots of bugs and ended up with ugly code. Sorry for this mess:
I like how this can still be used to solve day 2 😁
Ooh, now I have to load day 2’s code. 🤩
Took lots of my time today. Finally in swift
Here's my Python solution!
I found the directions for this challenge much more confusing - and my confusion led to some weird bugs! But ultimately I'm pretty happy with my solution (in ruby):
Today was a fairly mechanical extension of day 2. The details of the parameter modes are the trickiest part, with some instructions having implicit immediate or position mode. Not that hard overall however.
I extended my day2 C program which is now too long to post. See github.com/neilgall/adventofcode20...
This one was tough! Here is my solution walkthrough in javascript:
I'm lagging behind, but still moving.
Clojure code for Day 5