#//it’s cool and it’s only function is to make lambda feel cool which is neat

[mechahero]

uhhh boobie 

[oliverpdaniel]

Advent of Code 2020: Reflection on Days 1-7

All in all, a pretty simple week. Tougher points, for sure – though I was often coding at the stroke of midnight, and often with a brain addled with melatonin and ~other things~ – but nothing so revolutionary it couldn't be done.

Day 1: I must admit, this pandemic season made me forget all about the Advent of Code until December 2nd, when it popped up on my feed. So, Day 1 I had to do out of sequence. No problem.

As usual, Day 1 is just to help those who are unfamiliar with competitive-style programming get their feet wet with the input-algorithm-output workflow. The dataset was nowhere near big enough to cause the naive O(n^2)[1] solution not to work, so I decided to focus on making my solution elegant, Pythonic, and making appropriate use of the standard library. itertools.product came well in handy here, and using an iterator kept memory complexity lower than a list-based product.

My roommate's solution, conversely, was a deeply cursed Frankenstein's Monster of linear algebra. I still don't want to talk about it.

Fun fact: According to Reddit, the first star (i.e., Day 1 Part 1) was earned just 36 seconds after midnight, probably by someone with at least two monitors and a light-up keyboard.

Day 2: Whenever my brain sees regularly-formatted strings of different pieces of data, my Regex Lobe immediately starts firing synapses. Though, of course, as it was famously said:

If you have a problem and solve it using regex, you now have two problems.

Just some good ol' split() tokenization was all that was needed here. Python's comparison-chaining (e.g., lower <= x <= upper) syntactic sugar really helped here. I could have made it even more terse if I really wanted to – competitive programmers are usually averse to lines of code like:

counter = 0 if condition: counter += 1

But it really, really wasn't worth the effort here. Save that for days that start with 2, not end with it.

Day 3: This one gave me more trouble than I care to admit, and I actually had to revisit it later in the day. Ultimately, although I had immediately realized that this was a modulo problem (cf. simulation), I was having difficulty visualizing just where all the numbers needed to go. A little bit of funkiness with the ordering of lines in my algorithm here, but once I figured out Part 1, Part 2 was a breeze. Got to use a pretty cool looking slice –N[dy::dy] which ended up doing exactly what I needed it to do to handle the various slopes. Cool puzzle, and great winter theming!

Day 4: Glory to Arstotzka! Even though I solved this problem in Python as well, my roommate agreed that my solution was pretty friggin' JS-y. I ultimately caved to my reptillian regex brain, using a whopping 7 different re.match calls (though some of them were just out of additional caution, such as making sure certain numerical values were exactly 4 digits). Call me a UI dev, because I don't trust my input to be well-formed at all. Ever.

I also used a neat little field->validator function lookup table, though the clunkiness of Python's lambda keyword really starts to show itself. It's a shame van Rossum so vehemently opposes (opposed?) making Python more amenable to function-style programming. I learned a lot about it from my JS days, and it's often a very reusable way to solve problems. CAUSE NO TROUBLE.

Day 5: I've been had. My roommate got got too. I followed the problem directions too closely, not realizing the obvious solution right under my nose. Ugh. Maybe checking others' solutions on the AoC subreddit – after I finish my own, of course - is detrimental to my mental health.

My solution for Part 2, considering, is quite clever – I just sorted the list of flights, lopped off the first and last values, and enumerated it starting the index at whatever the second flight value was. Then, whenever there was a mismatch, we had found the gap. I saw others using the famous XOR hack, which was probably slightly more efficient than my list sorting. Oh well. I was too tired to be doing that kind of math.

Day 6: Every first week of a programming challenge needs a sets problem. I don't use sets very much at all, so I did it in a more programmer-oriented approach; my roommate, conversely, is a data scientist who lives and breathes sets, both in Python and math. He absolutely crushed my time on this one. (Not that it's a competition or anything...)

Day 7: The first challenge to give pause to both my roommate and me. The hardest part, to be honest, was just parsing the friggin' data. I tried to use regex again, if for no other reason than to flex my skills on my roommate. But, it turns out that Python regex doesn't support non-greedily capturing lists of repeated groups, i.e., r'([ab])+' will only ever capture a single letter, usually the first to satisfy it. So, matching on aba will just yield a single group of a. Sigh.

After doing it properly with some list comprehension-fu, it was a pretty straight shot, using some good ol' DFS on both parts to calculate paths. I was almost disappointed that the input data, despite being so intimidatingly large, allowed my relatively naive solutions (i.e., just checking every bag for Part 1 to see which led to shiny gold, and simple, non-tail-recursive sums in Part 2. Considering I just had a whole test on recursion efficiency in Racket, I should probably have done something smarter. Lol.) to run almost immediately. I was hoping to have to be clever to tackle the larger dataset.

To make myself feel better, I renamed my graph – really just a lookup table, tbh – SAURON, because it sees all. Also, I was tipsy and couldn't think of a better name. We live in a pandemic; leave me alone.

Anyway, this was a fun first week, and I'm looking forward to problems becoming increasingly head-scratching. My living room has a gigantic whiteboard in it for a reason.

[1]: TODO: add MathJax support to my blog :)