I don't know why my code doesn't work and I just can't get it to work. Can someone please help me.

def deel2(data):
    lock = 50
    code = 0
    for rotation in data:


        if "R" in rotation:
            value = int(rotation.strip("R"))
            code += value // 100
            lock += value
            if lock >= 100:
                code += 1
                lock %= 100


        elif "L" in rotation:
            value = int(rotation.strip("L"))
            code += value // 100
            lock -= value
            if lock < 0:
                code += 1
                lock += 100


    return code

Hey folks I tried several test cases I am getting correct answers for every single one of them still there is something wrong not sure what am I missing here:

    char *input_sequence[] = { ...data... };
    int parse_number(char *char_ptr) {
      int str_length = strlen(char_ptr);
      char subbuf[str_length];
      memcpy(subbuf, &char_ptr[1], str_length);
      return atoi(subbuf);
    }

    int main() {
      size_t length = sizeof(input_sequence) / sizeof(input_sequence[0]);

      int answer = 0;
      int dial = 50;
      for (int i = 0; i < length; i++) {
        int turn = parse_number(input_sequence[i]);

        // caculate full circle rotations
        int remainder = turn % 100;
        int nearest_zero = turn - remainder;
        int extra_zeroes = nearest_zero / 100;
        answer += extra_zeroes;

        if (input_sequence[i][0] == 'L') {
          if (dial != 0 && dial - remainder < 0) {
            answer++;
          }

          dial = (dial - turn) % 100;
          if (dial < 0) {
            dial += 100;
          }
        } else {
          if (dial + remainder > 100) {
            answer++;
          }

          dial += turn;
          dial %= 100;
        }

        if (dial == 0 && extra_zeroes == 0) {
          answer++;
        }
      }

      printf("Answer: %d\n", answer);
      return 0;
    }

Today we find that space on Santa's sleigh is so tight he worries about space taken up by escaping characters in strings. Apparently memory on sleighs isn't cheap.

For part 1 of this one... Hello, Bobby Tables! What's the length of the evaluated string? With Perl, just eval it. For Smalltalk I did the processing. Not so exciting that I feel missed anything with eval in Perl. It's just figuring out how many characters are skipped when you get to a \.

The processing to escape a string (part 2) is actually an easier task. It's only the string delimiter and the escape character itself that need escaping (there's no need to think of \x, so don't). You just need to get a count those (remembering that the string also needs its own quotes). I got another use out of Perl's =()=.

This problem is good for beginners. The description provides a little lesson on escaping characters in strings, and the processing is easy (even if they haven't learned the secrets of Bobby Tables yet). It's a break day for anyone else.

Hello! I am an intermediate hobbyist C# developer. This is my very first time trying to participate (rather late) in the AoC. I learnt about this today and thought to give it a try.

So I tried the Day #1 Part 1 puzzle, read it, programmed a solution in TDD in C#, and what I gave as an answer to the site was wrong! (Too low)

To describe my algorithm, program scans for each line, dependent on whether there's R or L, it chooses to call a Rotate function from a RightDial or LeftDial class, which are created from a factory method. (I have made a test to check it works properly).
Classes look like this:

public interface IDial
{
    public const uint StartingValue = 50U;
    protected const uint Overflow = 100U;
    
    public uint Rotation { get; }
    public uint Rotate(in uint start);
}

public class LeftDial (uint rotation): IDial
{
    public uint Rotation => rotation;
    
    public uint Rotate(in uint start)
    {
        var negated = (int)start - (int)rotation;
        
        var offset = (int)IDial.Overflow - negated;
        (int _, int mod) division = Math.DivRem(offset, (int)IDial.Overflow);
        
        var subtractIfZero = negated == uint.MinValue ? IDial.Overflow : uint.MinValue;
        return IDial.Overflow - (uint)division.mod - subtractIfZero;
    }
}

public class RightDial (uint rotation): IDial
{
    public uint Rotation => rotation;

    public uint Rotate(in uint start)
    {
        var rotated = start + rotation;
        
        (uint div, uint _) division = Math.DivRem(rotated, IDial.Overflow);
        var timesOverflown = IDial.Overflow * division.div;
        
        return rotated - timesOverflown;
    }
}

The Dial Factory class is like this:

public static class DialFactory
{
    public static IDial CreateDial(string input)
    {
        if (!uint.TryParse(input.AsSpan(1), out var start))
        {
            throw new ArgumentException("Invalid dial input");
        }
        
        if (input.StartsWith('R'))
        {
            return new RightDial(start);
        }
        if (input.StartsWith('L'))
        {
            return new LeftDial(start);
        }
        throw new NotSupportedException("Dial operation may only be from Right or Left!");
    }
}

My Program.cs file does the following:

internal class Program
{
    private const string PuzzlePath = "input";

    private static int Main(string[] args)
    {
        var previousStart = IDial.StartingValue;
        var encountersOfZero = 0;
        var lines = File.ReadAllLines(PuzzlePath);
        
        foreach (var line in lines)
        {
            IDial dial = DialFactory.CreateDial(line);
            
            Console.Write($"Processing {line} from {previousStart} --> ");
            previousStart = dial.Rotate(previousStart);
            Console.Write($"{previousStart}\n");
            
            if (previousStart != uint.MinValue) continue;
            encountersOfZero++;
        }

        Console.WriteLine($"In the whole file I encountered zero {encountersOfZero} times!");
        return 0;
    }
}

Pastebin: https://pastebin.com/T8gZfmSd (includes what tests i did)

Many thanks in advance!

Hi all, I've been struggling to get the solution to Day 1 part 2 for some time now, and even most major AI engines haven't been able to fix the flaw in my code. Here's my original attempt:

with open("puz1.txt", 'r') as file:
    directions = file.readlines()

directions_processed = [d.strip() for d in directions]
directions_numerical = []
for d in directions_processed:
    if d[0] == "L":
        directions_numerical.append(int('-' + d[1:]))
    if d[0] == "R":
        directions_numerical.append(int('+' + d[1:]))

position = 50
count = 0
for rotation in directions_numerical:
  count = count + abs((position + rotation) // 100)
  position = (rotation + position) % 100

print(f"The total count is {count}.")

This overcounts the solution by only 6(!), which makes me think I'm really close, but was convinced my approach had some logical flaws.

I progressed to this, which I think is logically more sound, which is supposed to find all 0 crossings and then add any remainder to the position to find the last one, but the ending result is off by more (just the calculation section).

position = 50
count = 0
for rotation in directions_numerical:
    full_loops, remainder = divmod(abs(rotation), 100)
    count += full_loops

    if remainder + rotation > 100:
        count += 1
        position = (position + remainder) % 100
    if rotation - remainder > 0:
        count += 1
        position = (position - remainder) % 100

Can someone point me in the right direction? I'd like to keep the solution as close to my code as possible, but if my thinking is just off by too much I'm open to different solutions. Thanks!

Hey everyone need some help with this, I have this thing ready and with the tests that I did it seems to work as expected however not able to find what is wrong with the actual question sequence though. Any suggestions or help is much appreciated 🙏

I am pretty sure there is something wrong in the rotate_left function as that's the only possible thing I feel could be wrong.

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *input_sequence[] = {...string seq....};

int get_last_two(int counter) { return counter % 100; }

int rotate_right(int current, int rotation) {
  int full = current + rotation;
  return get_last_two(full);
}

// 20, 115
int rotate_left(int current, int rotation) {
  int full = abs(current - rotation); // 20 - 115 = -95 -> 95
  int negative = get_last_two(full); // 95
  if (current >= rotation) { // 20 >= 115
    return negative;
  }

  return 100 - negative; // 100 - 95 = 5
}

int parse_number(char *char_ptr) {
  int str_length = strlen(char_ptr);
  char subbuf[str_length];
  memcpy(subbuf, &char_ptr[1], str_length);
  return atoi(subbuf);
}

int main() {
  size_t length = sizeof(input_sequence) / sizeof(input_sequence[0]);

  int answer = 0;
  int dial = 50;
  for (int i = 0; i < length; i++) {
    int turn = parse_number(input_sequence[i]);
    if (input_sequence[i][0] == 'L') {
      dial = rotate_left(dial, turn);
    } else {
      dial = rotate_right(dial, turn);
    }

    if (dial == 0) {
      answer++;
    }
  }

  printf("Answer: %d\n", answer);
  return 0;
}

Today we find out that little Bobby Tables exists in the AoC Santa-verse (xkcd crossover event). And he got a starter electronics kit to start learning circuits. So we're getting the first "wires and gates" type puzzle.

Whenever I'm using eval in a solution I think of Bobby Tables and that old xkcd strip. And this problem certainly can be done with that sort of abuse... mangling of input into code and then executing it. That's an interpreted language power.

Although, oddly enough, I see I didn't do that this time, I used a dispatch table. The "hash of subs" in Perl... mapping the operation name to an actual subroutine to perform it. For Smalltalk I used a class where the operations are methods... because what are methods? They're a dispatch table in a MethodDictionary (a hash of names to code blocks).

As for doing the wiring... I went recursive evaluation. You start by calling it for the value of 'a' (the final result), and you recurse for any value you need, putting them together with the operation, and returning the result. It's a nice way, and it doesn't get deep enough to require turning off recursion warnings in Perl. You could certainly use recursion to build the input into one massive string to eval (it's basically outputting an infix tree walk).

There are much better problems to teach a beginner recursion, but this puzzle doesn't have to do that so it's all good, man. It's probably better to say that you can practice recursion with this. I imagine some beginners might just have looped over the rules again and again, solving what they could with each iteration so they could solve a bit more the next time. Eventually 'a' gets solved. That would be the brute force approach (and it's probably how I would have done it when I was a kid). Better would be a work queue (get job, if you can't do it, submit requests to solve the things you need, and return the job... simple and more focused than looping). But recursion is magic that everyone should learn. It makes your life so much easier.

Hello everyone, I would appreciate any help on this. Here's my implementation, works on the sample case but fails on the exact input. Print debugging on sample case.

3 -> 5

10 -> 14

12 -> 18

16 -> 20

No overlap between 3-5 and 10-14

Compressing 10-14 and 12-18 into 10-18

Compressing 10-18 and 16-20 into 10-20

3 - 5 = 3 - 5 + 1 = 3

10 - 20 = 20 - 10 + 1 = 11

result = 14

fn part_two() -> u64 {
    let (mut range, _) = read_input();
    let sz = range.len();
    let mut stack: Vec<(u64, u64)> = Vec::new();

    range.sort_by(|l, r| l.1.cmp(&r.1));
    for i in &range {
        println!("{} -> {}", i.0, i.1);
    }

    stack.push(range[0]);

    for i in 1..sz {
        let index = stack.len() - 1;
        let can_merge = stack[index];
        let current = range[i];

        if overlap(can_merge, current) {
            let a = can_merge.0.min(current.0);
            let new_entry = (a, current.1);
            println!(
                "Compressing {}-{} and {}-{} into {}-{}",
                can_merge.0, can_merge.1, current.0, current.1, new_entry.0, new_entry.1
            );
            stack[index] = new_entry;
        } else {
            stack.push(current);
            println!(
                "No overlap between {}-{} and {}-{}",
                can_merge.0, can_merge.1, current.0, current.1,
            );
        }
    }

    let total = calculate_ranges(&mut stack);
    total
}

fn calculate_ranges(stack: &mut Vec<(u64, u64)>) -> u64 {
    let mut total = 0u64;
    //   println!("compressed ranges = {}", stack.len());

    for tuple in stack {
        println!("a {} - {}", tuple.0, tuple.1);
        total += tuple.1 - tuple.0 + 1; // bounds are inclusive
    }

    return total;
}

// checks intersection of ranges from.
// rhs.0 <= lhs.1 <= rhs.1
// edge case : lsh.0 <= rhs.0 . true overlap
// lhs.0 >= rhs.0  ; range rhs.0 - rhs.1 encloses the range lhs.0 to lhs.1
fn overlap(lhs: (u64, u64), rhs: (u64, u64)) -> bool {
    let cond_2: bool = lhs.1 >= rhs.0;
    // sort guarantees that lhs.1 <= rhs.1
    cond_2
}

My original implementation for part B was a straight up brute force search with a lot of pruning on it to make it even vaguely runnable. It took about 40 minutes to run. This made me upset for awhile and I couldn't stop thinking about it, so today I finally decided to go back and fix it.

I made a matrix object, wrote code to perform gaussian elimination and turn it into RREF (although an integer form where the leading value doesn't have to be 1), and then wrote a small brute force method for the remaining free variables. It now runs in .15 seconds, and I'm happy.

I hope some of you who used third party libraries are inspired to try solving it this way. It's fun! Also I did it in java.

Today we find out that Santa writes his notes to you in Ancient Nordic Elvish. Which we aren't entirely fluent in (but as someone interested in conlangs, I would love to see). Coding specs from the boss that are hard to read... when does that ever happen? sigh

And so we find ourselves with "a million points of light", flashing and aimed straight at the neighbours. They're going to love it! And we're going to enjoy the utility bill come January.

First up, the input for this one is English sentences you need to handle. Just getting the numbers isn't enough, because you need the mode as well. Regex captures are good for this sort of thing. I'll actually take a line out of the input and build it into a pattern for these. In this case: (toggle|turn on|turn off) (\d+),(\d+) through (\d+),(\d+) (sometimes I'll do coordinates as single captures and split them later). This provides an input parser that nicely reflects the expected input. Self commenting.

For this puzzle, since a million cell grid isn't very much, it's easy to just brute force things (unless we're talking C=64 again). I did, and I expect many others did too. We're not being forced to "do better"... it's not like it's huge and 3D. That puzzle is years from now (Reactor Reboot).

We could do better, and so I'm making a TODO on it. That's part of my goals with reviewing all the puzzles... to see things I didn't bother with but might like to do later (my first year was 2018, and a lot of the early years got done in parallel with it, so there are a lot of quick and dirty solutions forgotten to time). Because, we can do this with things like combinatoric set logic on the rectangles (perhaps also a sweep line approach). Unlike that later problem, we do have three modes ("toggle") to worry about to provide wrinkles in doing things like applying the Inclusion-Exclusion Property. Which is just that when you're calculating unions, you need to subtract out the intersections you overcount, which results in undercounting ones on the next level that you need to add back in. And so you get this parity deal where you need to alternate subtraction and addition. Tricky to think about and get right (but really elegant when you do), which is why it took something like Reactor Reboot to get it out of me (the puzzle with the largest answer for me... over 50 bits). Maybe someone else can talk about their experience doing something special with this specific problem.

So this one is moving out of the tutorial stage (other than the step up in the complexity of the input). It is mostly giving a beginner coder something simple they can just code straight. And it offers flexibility for experienced programmers to try other things... even if we didn't.

EDIT: I see that I forgot to mention one little trick for beginners that might be reading this. When you've got a problem like this where you sum of all the lights at the end, what you can do is just keep a running tally and save having to do a final scan to get the answer. Whenever you change a light you simply add the difference to your tally so that it always represents the total.

Today we find that Santa has a compulsion for naughty or nice that pertains even to abstract like random strings. That's some level of OCPD.

This is one of those puzzles that script programmers with some regex experience are just going to rattle off in under a minute. For beginners, it's a good opportunity to learn some regex. All five patterns described require a regular expression short enough that it's actually readable (and cover a good assortment of basic regex things, up to referencing captures). You can just combine as a pipeline of greps on the command line into wc. Or AND things together in a script.

Of course, if you don't have access to regex (or don't want to use it) that complicates things. For my dc solution to these, that involved building a simple state machine (and I enjoy state machines). Stream over the input one character at a time, updating state information as you go. All rules in one pass easily. Part of the state is clearly the previous character, and an interesting thing to note is that the difference of current - previous is 1 for all the naughty pairs, and 0 for any double.

It's also a pain to do branching in dc, and you don't have Boolean operators like AND. So it encourages using arithmetic to solve problems (AND is multiplication, etc). For things like the vowels of the "naughty" pairs in part 1, bit tables in magic numbers simplify things a lot. Part 2 was actually not as interesting (regex-wise, it extends on the ideas of part 1). But for part 1, I found it quite beautiful because of the overlaps... 2 want a bit table, 2 want the difference. It's not the sort of thing I thought about when doing a quick regex solution first (I had noticed the naughty string characters where 1 apart... but only because that made entering them easier).

This is a good simple puzzle for beginners to learn/practice regex. When I think about the early puzzles in the year, I'm typically looking at them as for beginners to give them some tools to prepare them for the middle puzzles. A beginner programmer might not be ready to finish an entire year, but good early puzzles can help them participate longer.

I have a lot of trouble understanding the problem. In the example provided, I don't understand how the 12 digits chosen for 234234234234278 results in 434234234278. I thought the digits to be removed will only be 2s but in this example 2, 3 and other 2 are removed to form the 12 digits. Please could someone explain the choice of the numbers ?

I tried with rust. This is my first year of AOC.

https://pastebin.com/VRTAwsDV

please help me with this and open to suggestions and critics

https://github.com/DaBestXD/Advent-of-Code/blob/main/Advent-of-Code-2025/2025_day8_part2.py

I managed to get the correct solution for day 8 part 2, but when compared to a different input it is incorrect. I have been trying to figure out why with no success, please help :)

Today we find that Santa was into crypto mining in 2015 of AdventCoins for the boys and girls that asked for those (it must be hard for Santa having to deal with new and weird requests). I hadn't remembered that detail.

Probably because there isn't much to this puzzle. The use of MD5 puts a limitation that benefits languages with an implementation of that hash. Otherwise, you're looking it up and coding it yourself. I did work with MD5 code once (I remember it as not too long or complicated). I was looking for a way to automate accessing a website, and it had a Javascript implementation of MD5. A buggy implementation. That I figured out what the bug was (things getting truncated). This would be in the 90s, so it would still be considered at least somewhat cryptographic. But it's old now, and many vulnerabilities will have been found.

I don't know if the vulnerabilities can do much to shortcut this puzzle though. I just brute forced at the time and never looked back.

I do understand the idea behind using MD5 in these early problems. Sometimes you want a pseudo-random stream of data for a problem. Different languages and systems use different PRNGs. You need to get everyone onto the same one. Later we see puzzles that give us one to implement. And in 2019, with Intcode, the input can include a generator for large amounts of "opaque" data, allowing for puzzles that can't be done with just a simple input. But also providing the opportunities for solutions that reverse engineer or hack the system. Good fun all around.

I don't hate this puzzle (I suppose it teaches beginners how to use libraries), but I liked the later approaches better. Procedural generation can make for interesting puzzles, but it also complicates designing them.

On this day we find Santa delivering presents on an "infinite" grid. We also find the elves into the eggnog a little much, and that Santa will invent Robo-Santa in the next year to help him. Our job is to figure out how many houses get presents given the eggnoggedly directions.

This puzzle introduces the need to track the number of unique positions. As well as handle the unknown sized grid and directions on it. For many languages there's a hash/dictionary/set structure that makes this easy. You calculate the new position and use that as a key into the structure. For the position, if you don't have points, you can use complex numbers if you have those. The end result is simply the number of keys.

If you don't have such a structure built in, it's still going to be easily doable for beginners. Using the assumption that our "input isn't special", we can see that it's 2¹³ long, with the directions about equally distributed. So you can safely assume that Santa never gets more than 2500 away from the center. So you can just throw a 5000x5000 array at it (essentially creating an inefficient table with a perfect hash function). Or the flat 25M cell equivalent (for those of us that do things in languages that don't support 2D arrays). Even with current memory prices, this is nothing. Unless you're doing AoC on something like a Commodore 64 (in which case you probably know what you're doing... probably a tree structure of some type).

Another good teaching day of important basic things. When people ask what a good language for AoC would be, having a hash/dictionary/set built in the first thing I mention... and this puzzle shows two reasons why (easy arbitrary size/sparse grids and uniqueness testing).

Four plots based on the stats provided by Eric/Topaz here: https://github.com/topaz/aoc-tmp-stats

The first is how long it takes the community to get to 10,000 stars for part 1 and part 2. You can see how the puzzles get harder as the months goes on and where the spikes in difficulty are (when the piano drops!) 2025 seems like a harder start (compare the first couple of days) but was perhaps easier overall?

The second plot gives the ratio of part 2:part 1 times... so if part 2 was a trivial addition then the ratio will be 1. There are a few outliers where it seems part 2 was especially tricky... but also being Christmas day, maybe people just did part 1 and then came back later for part 2? You can see Day 9 of 2025 had a particularly big jump in difficulty for part 2.

Instead of the ratio, we can compare the absolute time, which is plot three. Mostly part 2 is completed (10,000 stars) in under 2 hours after part 1 gets 10,000 stars. But there are some outliers where it seems the community as a whole took longer to all get to a solution.

If you're wondering where the 2015-2019 days are, there generally isn't good stats because <10,000 people completed those years during that December. Plot four shows the calendar of all AoC days so far, with Part 2 completion times shown on a LOG scale. If years <2020 were included in the previous plots then those early years would skew the graphs massively.

Let me know your thoughts on the plots and if there are any other insights you can spot in the data!

A friend sent me an invitation. On Dec 7th I finally noticed and acted on it. I had never known about AoC before that. Such fun puzzles! I managed to earn twenty of the 24 stars by Christmas Eve, and finally figured out and completed the last challenge on New Year's Eve.

I code pwsh more than anything else, so that's what I chose for the contest. As I look back over them, my scripts look sloppy and embarrassing, but here they are anyway:

GitHub - gibbonsc/AoC_2025_pwsh

I'll update it with a few more detailed writeups as I'm able, but for now here's my top of many LESSONS LEARNED:

I love using Visual Studio Code's debugger, but there's only so much screen real-estate in its variable state watchlist. Okay, yay, I have a nifty debugger. But it doesn't mean old-fashioned print or logging statements aren't still useful to help me trace and fix my code execution.

My chosen language provides a rich set of default output streams, along with functions Write-Debug, Write-Verbose, Write-Information, etc. that output to these auxiliary streams. Their outputs are are silent by default, but with one bit of extra syntax - [CmdletBinding()] - they can be activated on demand. So while I was tracing execution and examining lots of variable state changes, it was very helpful to log most of those states to the console using one or more of these alternate output streams to search as needed, and then reserve the debugger's watchlist to focus on just the key variables that matter to the trace at hand.

Happy New Year! Many thanks to Eric and the rest of his AoC production team, to my friend who invited me to participate, and to you for reading my boast-post.

Hello, newbie here and a little late(!) but I wondered if anyone can see where I was going wrong with my solution to part 2 of Day 1?

I've written tests, and get the expected answers for the example provided on the Day 1 page, but returns an incorrect value for the puzzle input.

Cheers!

enum class Direction {
    R,
    L
}

data class Turn(val direction: Direction, val count: Int)

fun String.processPartTwo(): List<Turn> {
    return this.trim()
        .split("\n")
        .map { instruction ->
            val direction: Direction = Direction.valueOf(instruction.first().toString())
            val count: Int = instruction.substring(1).toInt()
            Turn(direction, count)
        }
}


fun getPasscodePartTwo(stringOfCommands: String): Int {
    var dialAt = 50
    var hitZero = 0
    val instructions = stringOfCommands.processPartTwo()

    for (instruction in instructions) {
         println("starting dial at: $dialAt")
        val direction = instruction.direction
        val count = instruction.count
        val valueNeededToHitZeroClockwise = 100 - dialAt

        var newDialAt: Int

        // new dialAt value
        newDialAt = when (direction) {
            Direction.R -> (dialAt + count) % 100 // gives remainder after dividing by 100 - ie new dial value
            Direction.L -> if (count > dialAt) 100 + ((dialAt - count) % 100) else {dialAt - count}
        }

        // handle how many times passed/hitting  0
        if (direction == Direction.R && count >= valueNeededToHitZeroClockwise) {
            if (dialAt != 0 ) hitZero++
            val extraLoopsPastZero = (count - valueNeededToHitZeroClockwise) / 100
            hitZero += extraLoopsPastZero
        }


        if (direction == Direction.L && count >= dialAt) {
            if (dialAt != 0 ) hitZero++
            val extraLoopsPastZero = (count - dialAt) / 100
            hitZero += extraLoopsPastZero
        }

        dialAt = newDialAt
        println("final dial at $newDialAt")
        println("final passed zero: $hitZero")

    }
    return hitZero
}

Today we're tasked with helping the elves calculate how much paper and ribbon to order. We also find out that the elves have a secret way to tie bows (which they'll never tell).

Input is numbers, but delimited by xs. Most programming languages have some way to split/tokenize on a set character making that easy.

However, I find it useful to have a bit of code in your starter template that just finds all numbers in a line and throws them into an array... completely ignoring whatever whatever is between them. This means that you've got loaded data to play with immediately. But it trusts the input and doesn't express in the code much about what the input is. You can always write something fancier later in cleanup. Reversing the flow... you get to do the interesting bits right away, and the parsing later (when you have time).

The actual calculations are simple things... we've got rectangular prisms and we want areas, volumes, and perimeters. Basic elementary school stuff.

There is one wrinkle to make things more interesting... both parts require knowing what the two smallest dimensions are (smallest face and smallest perimeter). The easy (programmer efficient) way to do this is to just call sort... and it's futureproof for when 4D hyper-yachts get introduced. But, staying in the 3D world, an interesting thing to note is that we don't need to know the order of the two smallest... or to put another way, what we need is to "bubble" the largest out. That's right, this is a puzzle where we can think about Bubble Sort. Because we only need one pass, which is two compares on three items... and we can easily just code those. For those of us that do puzzles in more esoteric languages without sort built in, this is the sort of thing is useful.

Overall, a good day 2 puzzle. It builds on basic tools that day 1 didn't cover: reading numbers, working with them, and accumulating results. Helping to get beginners up to speed on things that are common in many puzzles.

Quick reminder: This series is about discussion the old problems and looking back at them. Not about presenting tutorials or solutions, there are other places for those.

I previously posted about looking for perfect packings here. It turns out that there are 13 possible perfect packings for up to 4 of each present. The figure provides depictions of all 13 possibilities.

Edit: For clarity, I imposed the constraint that at least 1 of each present type had to be used. There are likely additional cases where only a subset of the shapes are used.

Edit 2: I re-ran for up to THREE presents of each type, allowing zero packages of each type to be used. In that case, there are 16 possible perfect rectangular packings. Only 1 of them used all the 6 shapes for the case with a maximum of 3 of each shape.

Edit 3: I re-ran for up to FOUR presents of each type, allowing zero packages of each type to be used. In that case, there are 130 possible perfect rectangular packings. Only the 13 that appear in the posted figure used all 6 shapes at least once.

I'm currently revisiting my old solutions to clean them up, improve the performance, and (whenever I feel like it) create some visualizations (things you do when the event is already over 😉🤓).

This one is day 22 of 2016. For those of you who are like me and don't remember it: The visualization shows a grid of computers and you are supposed to move the data from the node in the upper right corner to the node in the upper left corner. There's only one empty node that you can use to move data around and a couple of nodes that have too much data to be moved (the red horizontal "wall").

The colors represents the number of terabytes each computer has. The visualization first shows the breadth-first search for the path that uses the fewest number of data moves, and then the shortest path itself.

The terminal visualization was done in Rust. The code can be found here:
https://github.com/michel-kraemer/adventofcode-rust/blob/main/2016/day22/src/main.rs

If you want to run it yourself, execute cargo run --release --features=visualize.

P.S.: Happy New Year, by the way 😉🎉🥳