Hello, there and welcome to my Advent of Code 2020 Day 3 cruise log. Last night I made a huge mistake. Since the UK got out of lockdown into a tier system that allows us to go and hum support businesses, I went and did just that.
Hello, there and welcome to my Advent of Code 2020 Day 3 cruise log. Last night I made a huge mistake. Since the UK got out of lockdown into a tier system that allows us to go and hum support businesses, I went and did just that.
The problem is that by the time we left, around 10 pm I was way past my 8.39 pm bedtime that allows for these 4.20 am awakenings. As a result, I overslept, at least as far as early AoC cycles are concerned.
Now down to the problem, first “labyrinth” of this season, we had to figure how many trees we’d run into based on a certain direction. By direction I mean vector. At least that’s how I interpreted it. I ran into a couple of issues throughout the first part. I kinda brushed off the “infinite repeat” part of the problem statement which first got me to hit some out of bounds exceptions. Wasn’t a big deal, it took me mere seconds to fix that.
From there my test passed and I was on my merry way to getting that first star of the day. Que nenni! No star yet, my result was off by quite a bit. Went through the code once more. After some fine print debugging I eventually figured what went wrong. I messed up my x reset logic. When reaching the end of the array, I needed to update x by subtracting the array length from it. So I did just that and the test still passed, even better the result changed with by input. In the end, I finally unlocked my first star of the day. But this wasn’t over.
Part two was about using the algorithm from part one but passing it different directions and multiplying the results. Simple enough right? Right? Well, it definitely should have been. First, I had to do a tiny extraction of my direction vector and created a new structure. Then, I reused that structure in my part one and validated that the application returned the same results. Behaviour maintained, check. Next, I implemented the tests for part two using the example. So far so good.
Now I run the tests and it fails. One of the directions returned the wrong result but all the others worked fine. After some swift debugging, I figured that my x reset logic was still wrong but somehow good enough for part one. Instead of subtracting the array length, I switched to applying it as a modulo on my x when reaching the end. It worked. Now we’re back on track. All the tests from the example pass. We’re chilling.
As I’m getting ready to claim the final star of the day, I execute the program again but got the dreaded marine screen of death. Wrong answer, value too large, gotta wait a minute. That’s where I got in trouble. I probably spent about an hour on that. Manually counting trees in a very unproductive manner.
This is when I decided to write another test but with a tiny surface where my bug might be more obvious. I went from testing on the 11×11 test input to a 31×20 test input extracted from the real 31×323 input all the way down to 3×3. The smallest input with large directions for x and y proved a winner. Way easier to count manually what the expected result should be and it leaves no room for confusion or doubt. A plus while the clock keeps ticking and the company top spot is fleeting away from me.
I counted for each direction and double-checked the expected results for each of them. Now that I have the right counts, it is time to turn this certainty into unit tests and fix that mess. All passed but one. The only test where the down direction had a value different from 1. It all clicked then. The test input may have passed my first test accidentally but not this time. I realised then that I played myself.
With that new insight, I went back to the implementation and it was clear as day. The first row I examine is for y = 1 then I increment by dy. It works as long as dy is 1. But when it is 2 as it was there, then it can’t be right because we’re off by one. I definitely missed that when doing the original method extraction. The fix is easy, I replaced my loop initialization of y to use dy and it worked! At least the test passed. A few seconds later, I rerun the program and get a value lower than the previous one. Which seems like a good sign since the wrong answer was referred to as too large. I enter it and voila, I hit that final star of the day.
In the end, I wasted a lot of time making mistakes I feel like I shouldn’t be making but I guess that is still a learning experience. And learning is always good. Even though that brings me back to last year’s Advent of Code where I couldn’t read either it seems.
Maybe the lesson here is that I shouldn’t start AoC challenges before 7 am. Let’s try tomorrow, maybe I’ll break that pattern.
Thank you for reading my Advent of Code 2020 Day 3 cruise log, I will see you tomorrow, maybe. In the meantime, you can check out my Go Cloud series about building and deploying a Golang app to AWS. Also, I will push my code on Github at CodingNagger/advent-of-code-2020 so feel free to check it out but not before you’ve done the challenge yourself. Bye!
The post The Advent of Code 2020 Day 3 log, off by one appeared first on Coding Nagger.
Top comments (0)