I considered doing more bit mashing, bit masking, bit matching today. I really did. Advent of Code, Day 20 backs the time commitment down from Day 19 far enough that it was tempting to spend time on efficiency. But a very tiny amount of pre-processing of these images and enhancement algorithms, makes a simpler route much more fun:
Replace every "#" character with a "1" character, and replace ever "." with a "0". Why? Because then the "image enhancement" lookup goes like this:
Zero bit manipulation. None. Just tell list_to_integer that the digits it is converting are in base 2. Is it the paragon of efficiency? For code production, yes, likely. I wouldn't try to use it on realtime video display.
My enhance function is a straightforward scan through every pixel from -1,-1 to Width+1,Height+1. I think the one interesting thing is a corner case I just happened to notice before I started coding: the background. The "image enhancement algorithm" in my puzzle input starts with a hash/one and ends with a dot/zero. This means when the scan area passes over an aread that is all dots/zeros, it inserts a hash/one pixel, and when it passes over an area that is all hashes/ones, it inserts a dot/zero pixel. This is rare in the middle of the interesting part of the image, but since we are to consider the canvas "infinite" it happens all the time! The "background" of my image blinks. My solution to the impossibility of flipping an infinite number of pixels was just to store which value all of them would have, and to get that value from flipping just one sample of all-background color.
To count on pixels, I used Erlang's binary generators and pattern matching to produce a list containing an integer 1 for every "1" character in the image. The sum of this list and its length are equivalent. Again, there ways to help the computer do this faster, but if I haven't worried about runtime efficiency yet today, why start now?
Today is another day where the difference between Part 1 and Part 2 is just, "run your code more times," like on Day 6, Day 14, and sort of Day 15. These images aren't large enough for the constraint to be an efficiency problem, though, even for naive solutions like mine. Was this an attempt to trip up solutions that pre-allocated the full finished image space?
It's good to see the puzzle difficulty step back a hair from Sunday. I thought that puzzle was fun, but I had plenty of time, focus, and energy to do it. I was not going to keep that up for six more days, though! As always, full code for my Day 20 solution is on github.
After watching more animations of people's solutions to each puzzle, I think I've realized that everyone's puzzle inputs are different (or at least that not everyone's are the same). If that's the case, tell me (@hobbyist): does your background blink?
Post Copyright © 2021 Bryan Fink