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 properly displaying registration markings is a bookable offense. Luckily, we are able to get our registration from the control-room elves. We just need our hull painting robot to take the code and paint our mark. We do have a hull painting robot, don't we?
Part 1 has us building an IntCode interpreter powered robot. We need to send the interpreter input (the color of the hull where it's standing) and use the output to move the robot and paint the hull.
Unfortunately, the simulation goes awry, and the robot paints a deliriously beautiful but meaningless picture. Worse, it's not a registration mark. We re-calibrate our starting color, and successfully. generate our registration code to complete Part 2.
Ongoing Meta
Dev.to List of Leaderboards
-
120635-5c140b9a
- provided by Linda Thompson
If you were part of Ryan Palo's leaderboard last year, you're still a member of that!
If you want me to add your leaderboard code to this page, reply to one of these posts and/or send me a DM containing your code and any theming or notes you’d like me to add. (You can find your private leaderboard code on your "Private Leaderboard" page.)
I'll edit in any leaderboards that people want to post, along with any description for the kinds of people you want to have on it. (My leaderboard is being used as my office's leaderboard.) And if I get something wrong, please call me out or message me and I’ll fix it ASAP.
There's no limit to the number of leaderboards you can join, so there's no problem belonging to a "Beginner" and a language specific one if you want.
Neat Statistics
I'm planning on adding some statistics, but other than "what languages did we see yesterday" does anyone have any ideas?
Languages Seen On Day 10
- JavaScript x 2
- Python x 2
- Kotlin
- Swift
Completion Stats
By applying a best-fit descending power trend-line to the 1 and 2 star columns on the stats page, my estimates predict:
2 stars on day 25: 6358 people
1 star on day 25: 420 people. Nice
If you're still going, take heart in that you are in a rapidly dwindling pool of people.
Doing other questionable statistics gives me: 415/6248
Top comments (11)
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...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.