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