IntCode's back, but his brain is inside the robot now.
Day 11 - The Problem
Oh no! The police have pulled us over! Apparently, not prop...
For further actions, you may consider blocking this person and/or reporting abuse
bit late but here you go Swift solution
Python!
I knew we were going to use IntCodes again! 🧐
But fortunately at this point I'm pretty confident of my routines, so I just copy+pasted most of it. Tweaked a bit since after each output it could or could not receive an input (the scanned color). Also ditched
BigInt
s since they are not necessary.So the main running cycle became (JavaScript ahead!):
For the rest, I'm keeping track of the coordinates, the direction (an integer between 0 and 3) and the last read panel color. Everything worked at the first try!
Part One
Part Two
Solution in JS
I used an object to represent the grid to make counting the "painted" block easier.
Had a bit of trouble realizing that the top left of the grid is 0,0 and not the bottom left :)
I ranked on the global leaderboard! Never thought I'd make it. Came in at 87th for both stars and 83rd for the first star.
Ruby solution for part 2
Not too bad. Follow the steps: Input -> Process -> Output -> Repeat and keep track of the touched squares in a hashmap. Could have gone full-hog and made structs out of points and headings, but this makes sorting easier. Here's my Rust solution:
Phew! More dumb bugs slowed me down! However, once I figured out what was wrong, I was able to simplify my input/output functions a little but overall just use the intcode from the Amplifier day.
Starting to experiment more with lenses, they're neat, but seem a little unnecessary so far? I don't think I've seen the use-case that really calls for it. Like seeing a food processor next to a nice knife block; why wouldn't I just use a knife to chop things?
Substantial refactor to my C IntCode machine for this one. I replaced the input/output buffers with function calls which call into the robot code. I also had the robot change the output function pointer on each paint/move, which seemed the simplest way to keep track of what to do on each output.
For part 2 I calculated the extent of painted panels and just visualised that rectangle. I needed a 200x100 grid to run my input program without running off the edge.
Despite a few segfaults in the early part of developing this one, I'm finding the C implementations of these problems the easiest, which is quite interesting as although I did my spell writing embedded firmware and Linux device drivers for a living 20 years ago, I haven't really done much C for ages.
Execution time today is 11ms.
not knowing size in advance made it tricky to print the result at first
github.com/LeonFedotov/advent-of-c...