Day 1: The Tyranny of the Rocket Equation

---

Links:

• Puzzle on adventofcode.com
• Source Code

So huh, this was nice and easy, wasn’t it. Of course I can’t really boast about it given the struggle I had to go through to get it working. Not the actual program solving logic, or any code for that matter, but everything around it. So first, let’s indulge the story of how I ended up solving the puzzle in Python’s console interpreter and only got to Rust at 1am the next day.

Also, I was quite curious about the name “tyranny of the rocket equation” so I did some digging and I found this NASA Feature. But it’s much more likely that I’ve heard the name from Randall Munroe’s “What If?” here.

Setting it up

I had almost forgotten that we’d already reached december when I looked at the date. Of course I didn’t bother setting up Rust beforehand so I had to do that first. Turns out I was missing the Visual Studio build tools (namely the C++ compiler) and being the package manager fan that I am, I of course wanted to use Chocolatey to install them. Well, that didn’t happen. At least not for a few hours, because as it turns out Chocolatey had severe issues that day and I wasn’t able to get it to download until about 10pm. Now I could’ve just used the normal way, but instead I was stubborn and waited for my beloved choco to come back.

When it finally worked it turned out that I had to install the actual build tools manually anyway. What a beautifully ironic twist.

TL;DR: Chocolatey broke and I had to wait. That’s it.

While waiting I decided to read through the puzzle’s description. Thinking “this sounds pretty easy” I got the urge to solve it using Python. Something along the line~~s~~ of the following did the trick:

sum(map(lambda v: v // 3 - 2, map(int, input("input:\n").splitlines())))

Oh how I love how concise this is. Keep it in mind, cherish it, because my Rust solution certainly isn’t this short.

I also solved the second part by using a recursive function instead of the lambda, but that’s not really the point of this.

Writing the framework

Since I wanted to go with a CLI approach again I looked for a command-line argument parser and it seemed that clap was still the best option out there.

But clap has certainly evolved. The GitHub page mentions that it absorbed another library called structopt which makes it possible to define the CLI structure like this:

#[derive(Clap)]
#[clap(version = "1.0", author = "Kevin K.")]
struct Opts {
    /// Sets a custom config file. Could have been an Option<T> with no default too
    #[clap(short = "c", long = "config", default_value = "default.conf")]
    config: String,
    /// Some input. Because this isn't an Option<T> it's required to be used
    input: String,
    /// A level of verbosity, and can be used multiple times
    #[clap(short = "v", long = "verbose", parse(from_occurrences))]
    verbose: i32,
    #[clap(subcommand)]
    subcmd: SubCommand,
}

I was really happy with the idea… BUT as it turns out this feature isn’t even in beta yet, so I used the old, verbose method instead. Still, working with clap was refreshingly convenient and it didn’t take long to get a decent interface working.

When it came to calling the appropriate puzzle I really wanted to use a more sophisticated method than using a big match statement. I tried a few methods but the problem was either passing around the function (because one has to use a reference to the function) or that the function had to adhere to the exact type (I wanted to allow the solvers to return any possible value) and I wasn’t willing to compromise. So, with applause, please welcome back the ol’ match method 2.0. It’s almost ironic that the current method also forces the solvers to return a specific type (string), which is something I really didn’t want…

Maybe I should’ve used a “Puzzle” trait, but this does the trick for now. I really hope I get the chance to refine this though.

The actual puzzle

Day 1 didn’t really offer much in terms of challenge, but that’s perfectly fine as it allowed me to focus on the other aspects. I went with a recursive solution for the second part, because that was faster to write. Other than that, there really isn’t anything to discuss here.

---

Overview
Next day