Eric Burden

Advent of Code 2023 - Day 25

Wed, 03 Jan 2024 00:00:00 +0000

It’s that time of year again! Just like last year, I’ll be posting my solutions to the Advent of Code puzzles. This year, I’ll be solving the puzzles in Kotlin. I’ll post my solutions and code to GitHub as well. If you haven’t given AoC a try, I encourage you to do so along with me!

Day 25 - Snowverload

Find the problem description HERE.

The Input - A Proponent of Components

Let’s celebrate Christmas Day with one more input where each line is a unique piece of information and that information has nice, distinct separators! Thanks, Eric Wastl! Unfortunately, since what we want is an undirected graph of (component1 <--> component2), and the input is only guaranteed to include that relationship in one direction, we need to do a bit of work to make sure we have both the forward and reverse edges in our data structure.


/**
 * Represents a single plugged in component
 *
 * These are derived from each of the three-letter names from the input. The
 * idea is that comparing integers and copying them around is marginally faster
 * than comparing and copying strings. I'm not actually sure if this really
 * is faster, but it's a nice idea.
 *
 * @property id Unique integer identifier for this [Component].
 */
data class Component(val id: Int) {
    companion object {
        /**
         * Parse a [Component] from a name in the input file
         *
         * Each three-letter name is converted to an integer by bit-shifting
         * each character to the left and 'or'-ing all the bits together.
         *
         * @param str A component name from the input file.
         * @return The [Component] represented by the three-letter name.
         * @throws Exception When `str` isn't a three-letter string.
         */
        fun fromString(str: String): Component {
            require(str.length == 3) {
                throw Exception("$str is not a valid [Component] name!")
            }

            val (c1, c2, c3) = str.toList().map { it.code }
            val id = c1.shl(16).or(c2.shl(8)).or(c3)
            return Component(id)
        }
    }
}

/**
 * This class represents an edge in the undirected [ComponentGraph]
 *
 * This class is useful because we want to represent edges between components
 * in our graph of components, and since the graph is undirected we want to
 * consider (A -> B) to be equal to (B -> A).
 *
 * @property c1 One [Component] in the edge.
 * @property c2 Another [Component] in the edge.
 */
data class ComponentEdge(val c1: Component, val c2: Component)


/**
 * This class represents the graph of connections between [Component]s
 *
 * The graph here consists of undirected connections between components. We
 * know from the puzzle text that there are two groups of heavily interconnected
 * components separated by three nodes that can be "cut" to produce two
 * distinct networks.
 *
 * @property graph A mapping of one component to the list of components that are
 * reachable from that component.
 */
data class ComponentGraph(val graph: MutableMap<Component, MutableList<Component>>) {

    companion object {
        /**
         * Produce an empty [ComponentGraph]
         *
         * @return A mutable [ComponentGraph] with no nodes or edges.
         */
        fun empty(): ComponentGraph {
            val graph = mutableMapOf<Component, MutableList<Component>>()
            return ComponentGraph(graph)
        }

        /**
         * Parse the lines from the input file into a [ComponentGraph]
         *
         * Each line represents a set of undirected connections, such that
         * "jqt: rhn xhk nvd" can be interpreted as (jqt <--> rhn),
         * (jqt <--> xhk), (jqt <--> nvd).
         *
         * @param lines The lines from the input file.
         * @return A [ComponentGraph] parsed from the input file.
         * @throws Exception If any component name fails to parse to a [Component].
         */
        fun fromInput(lines: List<String>): ComponentGraph {
            val graph = empty()
            lines.filter { it.isNotEmpty() }.flatMap { line ->
                val (keyStr, valueStr) = line.split(": ")
                val key = Component.fromString(keyStr)
                val values = valueStr.split(" ").map(Component::fromString)
                values.map { ComponentEdge(key, it) }
            }.forEach { graph.addEdge(it) }

            return graph
        }
    }

    /**
     * Add an edge to the [ComponentGraph]
     *
     * Technically, adds both the forward and reverse edges to the underlying
     * map.
     *
     * @param edge The [ComponentEdge] to add to the graph.
     */
    fun addEdge(edge: ComponentEdge) {
        val (c1, c2) = edge

        val c1Values = graph.getOrDefault(c1, mutableListOf())
        if (c2 !in c1Values) c1Values.add(c2)
        graph[c1] = c1Values

        val c2Values = graph.getOrDefault(c2, mutableListOf())
        if (c1 !in c2Values) c2Values.add(c1)
        graph[c2] = c2Values
    }
}



class Day25(input: List<String>) {

    // Turn that input file into a real graph!
    private val parsed = ComponentGraph.fromInput(input)
    
}

Why yes, I did jump through a few not totally necessary hoops there, but it’ll all be worth it when we solve the puzzle. Really, I probably should have gone with another builder pattern, something like a ComponentGraphBuilder so that the final ComponentGraph didn’t need to have a mutable inner data structure, but then I’d need to go back and re-factor again.

Part One - If At First You Don’t Succeed

So, according to our puzzle, we have two “clumps” of interconnected components with a three-component “bridge” between them, and we need to unplug those “bridge” components to bring down the star cost of running the snow-making machine. Sure hope that other half of the components aren’t really necessary.


// data class Component(val id: Int) { ... }

data class ComponentEdge(val c1: Component, val c2: Component) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is ComponentEdge) return false

        // Check equality regardless of the order of components
        return (c1 == other.c1 && c2 == other.c2) || (c1 == other.c2 && c2 == other.c1)
    }

    override fun hashCode(): Int {
        // Ensure the same hash code is generated regardless of the order
        // of components
        return c1.hashCode() * c2.hashCode()
    }
}


data class ComponentGraph(val graph: MutableMap<Component, MutableList<Component>>) {

    // companion object { ... }

    // fun addEdge(edge: ComponentEdge) { ... }

    /**
     * Return (one of) the component(s) that lies furthest from `start`
     *
     * Performs a comprehensive breadth-first search over the component graph,
     * starting with `start`, returning the last node found. In the event that
     * more than one component lies equally distant from `start`, there is no
     * guarantee as to which of these furthest components will be returned.
     *
     * @param start The component to start searching from.
     * @return One of the components that lies furthest from `start`.
     */
    fun furthestComponentFrom(start: Component): Component {
        val queue = ArrayDeque(listOf(start))
        val seen = mutableSetOf<Component>()
        var currentComponent = start

        while (queue.isNotEmpty()) {
            currentComponent = queue.removeLast()
            if (currentComponent in seen) continue
            seen.add(currentComponent)

            val nextComponents = graph.getOrDefault(currentComponent, listOf())
            for (nextComponent in nextComponents) {
                if (nextComponent in seen) continue
                queue.addFirst(nextComponent)
            }
        }

        return currentComponent
    }

    /**
     * Return the set of edges in _a_ constrained shortest path from `start` to `finish`
     *
     * Performs a breadth-first search from `start` to `finish`, returning
     * the set of edges in the first path found. In the event that there is
     * more than one equally short path, there is no guarantee as to which is
     * returned. Any edge in `excluded` will not be traversed when finding the
     * shortest path.
     *
     * @param start The first component in the path.
     * @param finish The last component in the path.
     * @param excluded A set of edges that are considered impassable for this
     * traversal.
     */
    fun pathExcludingEdges(
        start: Component,
        finish: Component,
        excluded: Set<ComponentEdge>
    ): Set<ComponentEdge>? {
        val queue = ArrayDeque(listOf(start to setOf<ComponentEdge>()))
        val seen = mutableSetOf<Component>()

        while (queue.isNotEmpty()) {
            val (component, path) = queue.removeLast()
            if (component in seen) continue
            if (component == finish) return path
            seen.add(component)

            val nextComponents = graph.getOrDefault(component, listOf())
            for (nextComponent in nextComponents) {
                if (nextComponent in seen) continue
                val edge = ComponentEdge(component, nextComponent)
                if (edge in excluded) continue
                queue.addFirst(nextComponent to path + edge)
            }
        }

        return null
    }

    /**
     * Count the number of reachable components from `start`
     *
     * Performs yet another variant of a breadth-first search, searching
     * outwards from `start` to find all connected nodes. Any edge contained
     * in `excluded` is considered impassable and nodes on the other side of
     * that edge may not be discoverable (unless they can be reached another
     * way).
     *
     * @param start The component to start searching from.
     * @param excluded The set of edges that cannot be traversed in this search.
     * @return The count of reachable components from `start`.
     */
    fun countReachableComponents(
        start: Component,
        excluded: Set<ComponentEdge>
    ): Int {
        val queue = ArrayDeque(listOf(start))
        val seen = mutableSetOf<Component>()

        while (queue.isNotEmpty()) {
            val component = queue.removeLast()
            if (component in seen) continue
            seen.add(component)

            val nextComponents = graph.getOrDefault(component, listOf())
            for (nextComponent in nextComponents) {
                if (nextComponent in seen) continue
                val edge = ComponentEdge(component, nextComponent)
                if (edge in excluded) continue
                queue.addFirst(nextComponent)
            }
        }

        return seen.size
    }
}



class Day25(input: List<String>) {

    // private val parsed = ...

    // Time to cut some components! For this final puzzle, we need to count
    // the number of components on either side of a three-component bridge
    // between two clusters of highly-connected components.
    fun solvePart1(): Int {
        // There are definitely some assumptions being made here, chief among
        // them that the two sub-graphs are relatively balanced on either side
        // of the cut-off (the hint being that we need to go from 100 stars
        // required to 50, i.e. remove half the components). We start by picking
        // a node at 'random', then finding the node furthest from it to serve
        // as a starting point. Then, we find the node furthest from `start`
        // and _assume_ it's on the other side of the three nodes we need to
        // disconnect.
        val aNode = parsed.graph.keys.take(1).single()
        val start = parsed.furthestComponentFrom(aNode)
        val finish = parsed.furthestComponentFrom(start)

        // Now, we find the shortest path from `start` to `finish` three times,
        // constraining the set of edges in these three paths to be unique (no
        // taking the same path twice). We still don't know _which_ three nodes
        // need to be disconnected, but if `start` and `finish` are on opposite
        // sides, we can be reasonably certain that they're in the list of
        // excluded edges we accumulate.
        val path1 = parsed.pathExcludingEdges(start, finish, setOf())
            ?: throw Exception("Could not find one path from $start to $finish!")
        val path2 = parsed.pathExcludingEdges(start, finish, path1)
            ?: throw Exception("Could not find two paths from $start to $finish!")
        val path3 = parsed.pathExcludingEdges(start, finish, path1 + path2)
            ?: throw Exception("Could not find three paths from $start to $finish!")
        val excludedEdges = path1 + path2 + path3

        // Now, with our list of excluded edges containing the only paths from
        // one sub-graph to another, we perform one more search over each side
        // of the cut-off, counting components in each. This bit assumes that
        // the components in each sub-graph are connected _enough_ that we'll
        // still be able to reach all of them despite our overly generous set
        // of excluded edges.
        val group1Size = parsed.countReachableComponents(start, excludedEdges)
        val group2Size = parsed.countReachableComponents(finish, excludedEdges)

        // Finally, we return the product of the two group sizes.
        return group1Size * group2Size
    }
}

Not going to lie, we played it kind of fast and loose with this one. I’m certain there are more general ways of identifying and removing the bridge or of just counting the interconnected clusters without needing to perform seven breadth-first searches over this graph, but I didn’t have the patience for it. On the plus side, that’s all fifty stars earned. Huzzah!

Part Two - Auld Lang Syne

If you haven’t heard, Day 25 - Part Two is always the “go back and finish the rest of the puzzles” challenge, so no extra coding needed here. Instead, I’d like to use this space to reflect on the Advent of Code puzzles for this year and my experience with them.

Has it really been four years since my first Advent of Code? Clearly the event has been around much longer, but it really seems like yesterday that a friend of mine was talking about this yearly set of coding puzzles he liked to do. This year was even more of a community event for me than in years past, with lots of activity on Mastodon of all places. I was also able to work with the organizer for the Carolina Code Conference and some other community members to brainstorm a “contest” for free conference tickets around Advent of Code participation. It was really nice to have some local folks also working on the puzzles and chatting about them in Slack.

Kotlin was a nice surprise as a language! I’d heard good things and it definitely lives up to the hype. I’ve written just enough Java to be dangerous as well as a bit of Clojure, but Kotlin was the first JVM language I’ve tried that I really enjoyed. I’d have to say the highlight was just how unsurprising the language is when compared to the syntax of other languages I’m used to. There are a couple of weird things (Why does passing anonymous functions require curly braces? What’s the deal with companion objects for class methods?), but for the most part, the syntax really managed to get out of my way for a language I’d not written more than 100 lines in previously. I will say the “non-IntelliJ” tooling left a bit to be desired. I started out trying to use the Kotlin LSP in both NeoVim (my preferred editor) and VSCode, but there were definitely some rough edges and performance issues there. I opted for Maven as a build system, and once I figured out that setup, it was fine. Figuring it out was a bit of a bear, though.

The other star of the show this year was ChatGPT. No, I didn’t ask it to solve the puzzles for me. I did ask a lot of questions like “How can I add a method to a class in Kotlin, not to an instance of that class?” and “Does the standard library have a ‘reduce’ function for lists?”. Compared to Googling and digging through the docs, having the (mostly) right information delivered to me in a concise format was really handy.

Just like last year, I’d like to send out a huge thank you to Eric Wastl and his crew of helpers for putting this event/phenomenon on and keeping it running. If you can, please consider donating to this effort to help keep the magic going, I guarantee there will be a lot of coders who will be glad you did.

If you’re interested, you can find all the code from this blog series on GitHub, please feel free to submit a pull request if you’re really bored. Happy Holidays!

Advent of Code 2023 - Day 24

Tue, 02 Jan 2024 00:00:00 +0000

Day 24 - Never Tell Me The Odds

Find the problem description HERE.

The Input - Hailstones in a Hurry

Today’s input represents a list of the positions and velocities (in the form of change in position per nanosecond) of hailstones, whizzing in surprisingly consistent trajectories through the air. Since we have nice, consistent line separators, parsing is pretty straightforward. Instead of integers, I’ll use Doubles for the numeric type, since we know from the puzzle that we’re going to need to handle decimal numbers.


/**
 * This class represents one of the hailstones.
 *
 * @property x The initial X-coordinate of the stone.
 * @property y The initial Y-coordinate of the stone.
 * @property z The initial Z-coordinate of the stone.
 * @property dx The initial X velocity of the stone.
 * @property dy The initial Y velocity of the stone.
 * @property dz The initial Z velocity of the stone.
 */
data class Hailstone(
    val x: Double,
    val y: Double,
    val z: Double,
    val dx: Double,
    val dy: Double,
    val dz: Double
) {
    companion object {
        /**
         * Parse a [Hailstone] from a line of the input file
         *
         * @param str The string representation of a [Hailstone].
         * @return The [Hailstone] represented by `str`.
         */
        fun fromString(str: String): Hailstone {
            val splitRegex = Regex("""[, @]+""")
            val numbers = str.split(splitRegex).map { it.toDouble() }

            // Still can't destructure a list with six item all at once.
            val (x, y, z) = numbers
            val (dx, dy, dz) = numbers.drop(3)

            return Hailstone(x, y, z, dx, dy, dz)
        }
    }
}

class Day24(input: List<String>) {

    // Parse each line from the input into a [Hailstone].
    private val parsed =
        input.filter { it.isNotEmpty() }.map(Hailstone::fromString)
}

With our stones in our pockets (so to speak), let’s get to calculating line intersections.

Part One - How Many Parsecs?

Looks like we’re producing hail instead of snow, and, just like Mother Nature, we’re contemplating the best way to smash those ice balls into smithereens to produce those lovely floating crystals we all know and love. That is how that works, right? Yes, of course it is. Now, we just need to see whether Mother Nature is already on the job or if she needs some help from us. For part one, “all” we need to do is determine for each pair of hailstones whether their paths moving forward in time will intersect on the X/Y plane.


/**
 * This class represents a rectangular region in 2D space.
 *
 * @property left The X-value of the left edge of the region.
 * @property right The X-value of the right edge of the region.
 * @property top The Y-value of the top edge of the region.
 * @property bottom The Y-value of the bottom edge of the region.
 */
data class Region2D(
    val left: Double, val right: Double, val top: Double, val bottom: Double
) {
    /**
     * Indicates whether an X/Y position is contained within the [Region2D]
     */
    fun contains(location: Pair<Double, Double>) =
        location.first in left..right && location.second in top..bottom
}

data class Hailstone( ... ) {
    // companion object { ... }

    /**
     * Find the X,Y intersection between the future paths of two hailstones
     *
     * Given that we can ignore both the time (partially) and the z-axis of
     * the paths of these hailstones, we're really looking at a system of
     * two equations and two unknowns. We can use the formula for finding the
     * intersection of two lines from:
     * https://en.wikipedia.org/wiki/Intersection_(geometry)#Two_line_segments.
     *
     * From what I understand, `t` (and `u`) represents the proportion along
     * the first line segment where it intersects with the second line segment.
     *
     * @param h2 The other hailstone whose path may intersect with this one.
     * @return The X/Y position of the intersection, if there is one. If the
     * lines are parallel, or the intersection occurred prior to the
     * hailstones' starting positions, return `null`.
     */
    private fun intersectionXYWith(h2: Hailstone): Pair<Double, Double>? {
        // These lines are parallel, they don't intersect
        val denominator = (dx * h2.dy) - (dy * h2.dx)
        if (denominator == 0.0) return null

        val h1 = this
        val t = ((h2.x - h1.x) * h2.dy - (h2.y - h1.y) * h2.dx) / denominator
        val u = ((h2.x - h1.x) * h1.dy - (h2.y - h1.y) * h1.dx) / denominator

        // Intersection is prior to the stones' initial position (negative
        // time).
        if (t < 0 || u < 0) return null

        // This is from the Wikipedia article as well!
        return (h1.x + t * h1.dx) to (h1.y + t * h1.dy)
    }

    fun intersectionIn2DRegion(h2: Hailstone, region2D: Region2D): Boolean {
        val intersection = intersectionXYWith(h2) ?: return false
        return region2D.contains(intersection)
    }
}

class Day24(input: List<String>) {

    // private val parsed = ...

    // For each unique pair of hailstones, identify whether the X/Y paths of the
    // hailstones will cross. Return the count of pairs that cross paths.
    fun solvePart1(region2D: Region2D): Int {
        var totalIntersectionsInRegion = 0
        for (i1 in 0 until parsed.size - 1) for (i2 in i1 until parsed.size) {
            val h1 = parsed[i1]
            val h2 = parsed[i2]
            if (h1.intersectionIn2DRegion(h2, region2D)) {
                totalIntersectionsInRegion += 1
            }
        }
        return totalIntersectionsInRegion
    }
}

I’m thinking that’s not going to be enough collisions without our intervention…

Part Two - There Is No Try

Yeah, let’s be honest, we knew we weren’t going to be able to ignore the Z-axis forever. But, what we couldn’t have expected (although maybe we should have) is that we’d be solving this problem with a rock. And linear algebra. Thankfully, my math is probably a bit better than my ability to throw a rock completely straight and with pinpoint accuracy over long distances. So, let’s go with math.


// data class Region2D( ... ) { ... }

data class Hailstone( ... ) {
    // companion object { ... }

    // private fun intersectionXYWith(h2: Hailstone): Pair<Double, Double>? { ... }

    // fun intersectionIn2DRegion(h2: Hailstone, region2D: Region2D): Boolean { ... }
}

/**
 * Solve a system of linear equations using Gaussian Elimination
 *
 * Yep, this comes from Wikipedia too. Specifically:
 * https://en.wikipedia.org/wiki/Gaussian_elimination. As I understand it, this
 * works by converting a system of linear equation into a simpler series of
 * equations.
 *
 * For the example, solving for the X, Y, dX, and dY components, the matrix
 * of coefficients is simplified like so:
 *
 *  [[-2, -1, -6, -1,  -44],     >     [[1, 0, 0, 0, 24],   (X)
 *   [-1,  1, -6,  2,    9],     >      [0, 1, 0, 0, 13],   (Y)
 *   [ 0,  1, -6, -8,   -3],     >      [0, 0, 1, 0, -3],   (dX)
 *   [-3, -2, 12,  8, -126]]     >      [0, 0, 0, 1,  1]]   (dY)
 * 
 * This is called the "reduced row echelon" form, and achieving this state means
 * that our constants on the right-hand side of the equation _is_ the value for
 * the unknown variable, like:
 *    
 *    -2X - 1Y -  6dX - 1dY =  -44  ->  1X + 0Y + 0dX + 0dY = 24  ->  X = 24
 *    -1X + 1Y -  6dX + 2dY =    9  ->  0X + 1Y + 0dX + 0dY = 13  ->  Y = 13
 *     0X + 1Y -  6dX - 8dY =   -3  ->  0X + 0Y + 1dX + 0dY = -3  -> dX = -3
 *    -3X - 2Y + 12dX + 8dY = -126  ->  0X + 0Y + 0dX + 1dY =  1  -> dy =  1
 *
 * @param coefficients The coefficients of the system of linear equations.
 * @return The coefficients on the right-hand side of the simplified system
 * of equations.
 */
fun gaussianElimination(coefficients: List<MutableList<Double>>): List<Double> {
    val rows = coefficients.size
    val cols = coefficients.first().size

    // This only works on a square matrix (with one extra column for the
    // coefficient on the right-hand side of the equation).
    require(rows == cols - 1) {
        throw Exception(
            "The number of coefficients on the left side of the" +
                    "equation should be equal to the number of equations."
        )
    }

    // We operate on each row in the matrix of coefficients.
    for (row in coefficients.indices) {

        // Normalize the row starting with the diagonal value of each row.
        val pivot = coefficients[row][row]
        for (col in coefficients[row].indices) {
            coefficients[row][col] /= pivot
        }

        // Sweep the other rows with `row`
        for (otherRow in coefficients.indices) {
            if (row == otherRow) continue

            val factor = coefficients[otherRow][row]
            for (col in coefficients[otherRow].indices) {
                coefficients[otherRow][col] -= factor * coefficients[row][col]
            }
        }
    }

    return coefficients.map { it.last() }.toList()
}

class Day24(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(region2D: Region2D): Int { ... }

    /**
     * Argh! It's geometry! And linear algebra! Yuck. Here's how this goes:
     *
     * Say the rock we want to throw to smash all the hailstones starts out at
     * xR, yR, zR, dxR, dyR, dzR, but we don't actually know what any of those
     * values is. We can start "simply" by identifying where on each axis
     * and when as time (t) the rock should collide with one hailstone
     * (with properties of, say: x, y, z, dx, dy, dz) as:
     *
     *      xR + (t * dxR) = x + (t * dx)
     *      yR + (t * dyR) = y + (t * dy)
     *      zR + (t * dzR) = z + (t * dz)
     *
     * Rearranging to solve for `t`, we get:
     *
     *      t = (xR - x)/(dx - dxR) = (yR - y)/(dy - dyR) = (zR - z)/(dz - dzR).
     *
     * For _just_ two axes (start with X/Y again), we can isolate the
     * values related to just the rock (which won't change from one hailstone
     * to another in order to solve the puzzle) by rearranging the relationship
     * between the X and Y axes like so:
     *
     *      (xR - x)/(dx - dxR) = (yR - y)/(dy - dyR)
     *      (xR - x)(dy - dyR)  = (yR - y)(dx - dxR)
     *      xR*dy - x*dy - xR*dyR + x*dyR = yR*dx - yR*dxR - y*dx + y*dxR
     *      yR*dxR - xR*dyR = yR*dx - y*dx + y*dxR - xR*dy + x*dy - x*dyR
     *
     * Because the terms (yR*dxR - xR*dyR) should be the same no matter which
     * hailstone we consider (in order to hit all the hailstones), we can
     * alternatively consider another hailstone with properties of, say:
     * x', y', z', dx', dy', dz', like so:
     *
     *      yR*dxR - xR*dyR = yR*dx' - y'*dx' + y'*dxR - xR*dy' + x'*dy' - x'*dyR
     *
     * Because (yR*dxR - xR*dyR) is unchanging, it must be true that:
     *
     *      yR*dx - y*dx + y*dxR - xR*dy + x*dy - x*dyR = yR*dx' - y'*dx' + y'*dxR - xR*dy' + x'*dy' - x'*dyR
     *      (dy'-dy)xR + (dx - dx')yR + (y - y')dxR + (x' - x)dyR = y*dx - x*dy -y'*dx' + x'dy'
     *
     * Since we need to solve for the properties of the rock, we can substitute
     * the actual values from any pair of hailstones into this equation. We'll
     * need at least four pairs of hailstones to solve for the four unknowns.
     *
     * We can perform the same rearrangement for the X and Z axes like so:
     *
     *      (xR - x)/(dx - dxR) = (zR - z)/(dz - dzR)
     *      (xR - x)(dz - dzR)  = (zR - z)(dx - dxR)
     *      xR*dz - x*dz - xR*dzR + x*dzR = zR*dx - zR*dxR - z*dx + z*dxR
     *      zR*dxR - xR*dzR = zR*dx  -  z*dx  + z*dxR  - xR*dz  + x*dz   - x*dzR
     *                      = zR*dx' - z'*dx' + z'*dxR - xR*dz' + x'*dz' - x'*dzR
     *      zR*dx - z*dx + z*dxR - xR*dz + x*dz  - x*dzR = zR*dx' - z'*dx' + z'*dxR - xR*dz' + x'*dz' - x'*dzR
     *      (dz'-dz)xR + (dx - dx')zR + (z - z')dxR + (x' - x)dzR = z*dx - x*dz -z'*dx' + x'dz'
     *
     * The neat thing is, if we already know xR and dxR from solving the first set
     * of equations, then we only have two unknowns remaining (zR and dzR), for
     * which we only need two pairs of hailstones by rearranging the system of
     * equations like:
     *
     *       (dx - dx')zR + (x' - x)dzR = z*dx - x*dz -z'*dx' + x'dz' - (dz'-dz)xR - (z - z')dxR
     *
     *  Now, let's get solving!
     */
    fun solvePart2(): Long {
        val (rockX, rockY, rockDX, rockDY) = gaussianElimination(
            parsed.take(5).windowed(2).map { (h1, h2) ->
                // This comes from:
                // (dy'-dy)xR + (dx - dx')yR + (y - y')dxR + (x' - x)dyR = y*dx - x*dy -y'*dx' + x'dy'
                mutableListOf(
                    h2.dy - h1.dy,  // (dy' - dy)
                    h1.dx - h2.dx,  // (dx - dx')
                    h1.y - h2.y,    // (y - y')
                    h2.x - h1.x,    // (x' - x')

                    // This is the right-hand side of the equation, or
                    // y*dx - x*dy -y'*dx' + x'dy'
                    ((h1.y * h1.dx) + (-h1.x * h1.dy) + (-h2.y * h2.dx) + (h2.x * h2.dy))
                )
            }).map { it.roundToLong() } // Prevents issues with precision

        val (rockZ, rockDZ) = gaussianElimination(
            parsed.take(3).windowed(2).map { (h1, h2) ->
                mutableListOf(
                    // This comes from:
                    // (dx - dx')zR + (x' - x)dzR = z*dx - x*dz -z'*dx' + x'dz' - (dz'-dz)xR - (z - z')dxR
                    h1.dx - h2.dx,  // (dx - dx')
                    h2.x - h1.x,    // (x' - x)

                    // This is the right-hand side again
                    //  z*dx - x*dz - z'*dx' + x'dz' - (dz'-dz)xR - (z - z')dxR
                    // @formatter:off
                    ( (h1.z  * h1.dx)                       // z*dx
                    - (h1.x  * h1.dz)                       // x*dz
                    - (h2.z  * h2.dx)                       // z'*dx'
                    + (h2.x  * h2.dz)                       // x'*dz'
                    - ((h2.dz - h1.dz) * rockX.toDouble())  // (dz'-dz)xR
                    - ((h1.z  - h2.z)  * rockDX))           // (z - z')dxR
                    //@formatter:on
                )
            }).map { it.roundToLong() }

        // We've solved for all the necessary parameters now, return the sum!
        return rockX + rockY + rockZ
    }
}

I (re)learned a lot about solving systems of equations today, including learning about Gaussian Elimination for the first time. Neat!

Wrap Up

Today’s problem really showcased the value of math. I really needed to access a number of resources (articles and videos) to understand exactly how the math worked. I never had the benefit of a linear algebra course in college, which is kind of a shame since working through these kinds of rearrangements is really fun. It took me a while post-holiday travels to get back to Advent of Code and the blog, and this was a nice puzzle to nearly wrap up the year with.

Advent of Code 2023 - Day 23

Sat, 23 Dec 2023 00:00:00 +0000

Day 23 - A Long Walk

Find the problem description HERE.

The Input - A Long Walk Down a Short Slope

Hello, grid of characters, my old friend! Today’s input parsing is another in a proud line of character grids to parse. Here we go!


/**
 * This class represents one of the tiles in the hiking map
 *
 * I opted to try something a little different with my tiles this time. Instead
 * of having each type be an enum, I'm having each type of tile derive from
 * this [AbstractPathTile] with a set function for identifying indices around
 * it for possible next path steps.
 *
 * @property position The position of this tile in the grid.
 */
abstract class AbstractPathTile(val position: Utils.Index2D) {
    companion object {
        /**
         * Create a concrete instance of an [AbstractPathTile] represented by a character
         *
         * @param char The character that represents the kind of [AbstractPathTile].
         * @param position The position of this tile in the grid.
         * @return The [AbstractPathTile] represented by `char` at `position`.
         * @throws Exception When `char` doesn't represent an [AbstractPathTile].
         */
        fun fromChar(char: Char, position: Utils.Index2D) =
            when (char) {
                '.' -> OpenPath(position)
                '#' -> Impassable(position)
                '>' -> EastSlope(position)
                '<' -> WestSlope(position)
                '^' -> NorthSlope(position)
                'v' -> SouthSlope(position)
                else -> throw Exception("Cannot parse $char to a path tile!")
            }
    }

    // Concrete classes will use these to determine which neighboring 2D
    // indices are possible next destinations for taking a step.
    abstract val offsets: List<Utils.Offset2D>

    // Possible neighboring indices are comprised of the current position
    // plus each of this class's offsets.
    fun possibleNeighbors(): List<Utils.Index2D> = offsets.map { position + it }
}

// This class represents an open tile, from which a hiker can proceed in any
// of the four cardinal directions.
class OpenPath(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf(
        Utils.Offset2D(-1, 0),
        Utils.Offset2D(1, 0),
        Utils.Offset2D(0, -1),
        Utils.Offset2D(0, 1)
    )
}

// This class represents an impassable tile. A hiker cannot proceed from
// such a tile.
class Impassable(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf<Utils.Offset2D>()
}

// This class represents a slope to the east. A hiker can only proceed
// east from this tile.
class EastSlope(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf(Utils.Offset2D(0, 1))
}

// This class represents a slope to the west. A hiker can only proceed
// west from this tile.
class WestSlope(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf(Utils.Offset2D(0, -1))
}

// This class represents a slope to the north. A hiker can only proceed
// north from this tile.
class NorthSlope(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf(Utils.Offset2D(-1, 0))
}

// This class represents a slope to the south. A hiker can only proceed
// south from this tile.
class SouthSlope(position: Utils.Index2D) : AbstractPathTile(position) {
    override val offsets = listOf(Utils.Offset2D(1, 0))
}

/**
 * This class represents the entire map of the hiking trail.
 *
 * @property grid The grid of tiles in this hiking map.
 */
data class HikingMap(val grid: List<List<AbstractPathTile>>) {
    companion object {
        /**
         * Parse the input into a hiking map
         *
         * @param input The grid of characters from the input file.
         * @return The [HikingMap] represented by the input file.
         * @throws Exception If any character in the input file can't be parsed
         * into an [AbstractPathTile].
         */
        fun fromInput(input: List<List<Char>>): HikingMap {
            val grid = input.withIndex().map { (rowIdx, row) ->
                row.withIndex().map { (colIdx, char) ->
                    val idx = Utils.Index2D(rowIdx, colIdx)
                    AbstractPathTile.fromChar(char, idx)
                }
            }
            return HikingMap(grid)
        }
    }

    // Rows and columns in the hiking map
    private val rows: Int get() = grid.size
    private val cols: Int get() = grid.first().size

    // The start and end tiles in this map.
    val start: OpenPath
        get() = (grid.first().find { it is OpenPath } as OpenPath?)!!
    val finish: OpenPath
        get() = (grid.last().find { it is OpenPath } as OpenPath?)!!
        
}

class Day23(input: List<List<Char>>) {

    // Make a map!
    private val parsed = HikingMap.fromInput(input)
    
}

Yeah we did! Having the tiles as subclasses kind of seems nice. I like it!

Part One - Nature Lover

Well, well, well. It’s almost Christmas and we’ve got enough leisure time to take a nice hike! A just reward for a job well done. In fact, we have so much free time that we can design an algorithm to find the longest possible walk for ourselves. Heck yeah!


abstract class AbstractPathTile(val position: Utils.Index2D) {
    // companion object { ... }

    // abstract val offsets: List<Utils.Offset2D>

    // fun possibleNeighbors(): List<Utils.Index2D> = ...
}

// class OpenPath(position: Utils.Index2D)   : AbstractPathTile(position) { ... }
// class Impassable(position: Utils.Index2D) : AbstractPathTile(position) { ... }
// class EastSlope(position: Utils.Index2D)  : AbstractPathTile(position) { ... }
// class WestSlope(position: Utils.Index2D)  : AbstractPathTile(position) { ... }
// class NorthSlope(position: Utils.Index2D) : AbstractPathTile(position) { ... }
// class SouthSlope(position: Utils.Index2D) : AbstractPathTile(position) { ... }

data class HikingMap(val grid: List<List<AbstractPathTile>>) {
    // companion object { ... }

    // private val rows: Int get() = ...
    // private val cols: Int get() = ...
    // val start: OpenPath  get() = ...
    // val finish: OpenPath get() = ...

    /**
     * Attempt get the tile from the map at `idx`
     *
     * If the index is a valid index in the map *and* the tile is passable,
     * return the tile. Otherwise, return null.
     *
     * @param idx The index to attempt to fetch a tile from.
     * @return An [AbstractPathTile] if the index is valid, else null.
     */
    private fun getOrNull(idx: Utils.Index2D): AbstractPathTile? {
        val inBounds = idx.row in 0..<rows && idx.col in 0..<cols
        if (inBounds && grid[idx.row][idx.col] !is Impassable) {
            return grid[idx.row][idx.col]
        }
        return null
    }

    /**
     * Return the length of the longest path from start to finish.
     *
     * @return The length of the longest path through the map.
     */
    fun longestPathThrough(): Int {
        // This will be an exhaustive depth-first search. Each item in the stack
        // consists of a tile and the path taken to get to that tile. This path
        // is used to ensure that we don't make a loop while walking along the
        // trail.
        val stack =
            mutableListOf(start as AbstractPathTile to listOf(start.position))
        var maxPathLength = 0

        // So long as we have paths left to explore...
        while (stack.isNotEmpty()) {
            // Get the last tile and path. If we're at the finish line,
            // recalculate the maximum path length and move on to another path.
            val (tile, pathToTile) = stack.removeLast()
            if (tile == finish) {
                maxPathLength = maxOf(maxPathLength, pathToTile.size - 1)
                continue
            }

            // Add each reachable, neighboring tile (and the path to it) to
            // the stack.
            val neighbors = tile.possibleNeighbors().mapNotNull { getOrNull(it) }
            for (neighbor in neighbors) {
                if (neighbor.position in pathToTile) continue // No loops!
                stack.add(neighbor to pathToTile + neighbor.position)
            }
        }

        return maxPathLength
    }
        
}

class Day23(input: List<List<Char>>) {

    // private val parsed = ...

    // Find the longest path through the hiking trail, navigating those
    // slippery slopes!
    fun solvePart1(): Int = parsed.longestPathThrough()
    
}

You know what, all this fresh air and sunshine has us feeling strong! What if…

Part Two - Uphill Climb

These slopes are nothing! We’re feeling plenty strong to walk up any slope we encounter. This will let us take a much longer route through the trails. And it means we really need to check more paths!


abstract class AbstractPathTile(val position: Utils.Index2D) {
    // companion object { ... }

    // abstract val offsets: List<Utils.Offset2D>

    // fun possibleNeighbors(): List<Utils.Index2D> = ...
}

// class OpenPath(position: Utils.Index2D)   : AbstractPathTile(position) { ... }
// class Impassable(position: Utils.Index2D) : AbstractPathTile(position) { ... }
// class EastSlope(position: Utils.Index2D)  : AbstractPathTile(position) { ... }
// class WestSlope(position: Utils.Index2D)  : AbstractPathTile(position) { ... }
// class NorthSlope(position: Utils.Index2D) : AbstractPathTile(position) { ... }
// class SouthSlope(position: Utils.Index2D) : AbstractPathTile(position) { ... }

data class HikingMap(val grid: List<List<AbstractPathTile>>) {
    // companion object { ... }

    // private val rows: Int get() = ...
    // private val cols: Int get() = ...
    // val start: OpenPath  get() = ...
    // val finish: OpenPath get() = ...

    // private fun getOrNull(idx: Utils.Index2D): AbstractPathTile? { ... }

    // fun longestPathThrough(): Int { ... }

    /**
     * Return a copy of this [HikingMap] with all the slopes removed
     *
     * @return A copy of this map with all the slopes removed.
     */
    fun dryUpTheTrails(): HikingMap {
        // Convert each slope to an [OpenPath].
        val grid = grid.map { row ->
            row.map { tile ->
                when (tile) {
                    is NorthSlope -> OpenPath(tile.position)
                    is WestSlope -> OpenPath(tile.position)
                    is EastSlope -> OpenPath(tile.position)
                    is SouthSlope -> OpenPath(tile.position)
                    else -> tile
                }
            }
        }
        return HikingMap(grid)
    }

    /**
     * From a given starting tile, find the next adjacent junctions
     *
     * A junction is any tile where the path branches or the start/finish tiles.
     * We're searching for these to try to cut down on the number of steps
     * needed to algorithmically walk all the paths when they're not restricted
     * by slopes.
     *
     * @param start The [AbstractPathTile] to start from.
     * @return A list of the next reachable junctions and the number of steps
     * to each.
     */
    private fun nextJunctions(start: AbstractPathTile): List<Pair<Int, AbstractPathTile>> {
        // This is another DFS with a twist, searching along pairs of
        // <step count> : <path tile>
        val stack = mutableListOf(0 to start)
        val seen = mutableSetOf<AbstractPathTile>()

        // This is the list of found junctions.
        val junctions = mutableListOf<Pair<Int, AbstractPathTile>>()

        // So long as there are tiles left to search.
        while (stack.isNotEmpty()) {
            // Get the next tile, and if we haven't already searched it...
            val (steps, tile) = stack.removeLast()
            if (tile in seen) continue
            seen.add(tile)

            // Find all the neighbors!
            val neighbors = tile.possibleNeighbors()
                .mapNotNull { getOrNull(it) }
                .filter { it !in seen }

            // If this tile is a junction (multiple neighbors) or is
            // the finish line, add it to the list of junctions and
            // move on.
            if (steps > 0 && (neighbors.size > 1 || tile == finish)) {
                junctions.add(steps to tile)
                continue
            }

            // Otherwise, add each neighboring tile and the number of steps
            // it took to reach it to the stack.
            for (neighbor in neighbors) {
                stack.add(steps + 1 to neighbor)
            }
        }

        // Return the list of junctions
        return junctions
    }

    /**
     * Convert this [HikingMap] into a [JunctionMap]
     *
     * A [JunctionMap] serves as a directed acyclic graph through the
     * [HikingMap]. This cuts down on the amount of work needed to search
     * through paths by simplifying the path from junction to junction.
     *
     * @return The [JunctionMap] derived from this [HikingMap].
     */
    fun toJunctionMap(): JunctionMap {
        // Yet another DFS with a twist! In this case, we're building up a
        // DAG of the junctions.
        val stack = mutableListOf(start as AbstractPathTile)
        val seen = mutableSetOf<AbstractPathTile>()
        val map =
            mutableMapOf<AbstractPathTile, List<Pair<Int, AbstractPathTile>>>()

        // For each junction tile still in the stack...
        while (stack.isNotEmpty()) {
            // If this junction hasn't been explored yet...
            val junction = stack.removeLast()
            if (junction in seen) continue
            seen.add(junction)

            // Get the next junctions! Add the mapping from the current
            // junction to the next junctions to our map.
            val nextJunctions = nextJunctions(junction)
            map[junction] = nextJunctions

            // Explore each of the next junctions.
            for ((_, nextJunction) in nextJunctions) {
                if (nextJunction in seen) continue // No loops!
                stack.add(nextJunction)
            }
        }

        return JunctionMap(map)
    }
}

/**
 * This class represents a map through path junctions.
 *
 * @property A mapping of tile -> [(steps, tile)].
 */
data class JunctionMap(val map: Map<AbstractPathTile, List<Pair<Int, AbstractPathTile>>>) {
    /**
     * Find the longest path through the [JunctionMap]
     *
     * @param start The starting tile.
     * @param finish The ending tile.
     * @return The number of steps in the longest path through the [JunctionMap].
     */
    fun longestPath(start: AbstractPathTile, finish: AbstractPathTile): Int {
        // That's right, DFS *again*!!!!
        val stack = mutableListOf(0 to (start to listOf(start)))
        var maxPathLength = 0

        // You know the drill...
        while (stack.isNotEmpty()) {
            // For each step not yet explored...
            val (steps, path) = stack.removeLast()
            val (tile, pathToTile) = path

            // If we've reached the end with this path, recalculate max path.
            if (tile == finish) {
                maxPathLength = maxOf(maxPathLength, steps)
                continue
            }

            // Explore the next junction along each path.
            for ((nextSteps, nextTile) in map[tile]!!) {
                if (nextTile in pathToTile) continue
                stack.add(steps + nextSteps to (nextTile to pathToTile + nextTile))
            }
        }

        return maxPathLength
    }
}

class Day23(input: List<List<Char>>) {

    // private val parsed = ...
    
    // fun solvePart1(): Int = ...

    // Slopes are no match for us! Finding the longest way around while
    // climbing up those slopes!
    fun solvePart2(): Int {
        val driedHikingMap = parsed.dryUpTheTrails()
        val junctionMap = driedHikingMap.toJunctionMap()
        return junctionMap.longestPath(
            driedHikingMap.start,
            driedHikingMap.finish
        )
    }
    
}

I’ve kind of lost track of the number of depth-first searches I did there. Like four, I think. I’m pretty sure there’s a better way to do this, but I’m too tired from all that hiking to come up with one.

Wrap Up

I spent lot of time on this one, so here are my thoughts simply: It works! It’s ugly. But, it works! Yay!

Advent of Code 2023 - Day 22

Fri, 22 Dec 2023 00:00:00 +0000

Day 22 - Sand Slabs

Find the problem description HERE.

The Input - A Brick of What?

Today, our input is a bunch of bricks, each of which can be represented by a group of “voxels”, or really just chunky points in 3D space. So, that’s how I’ll proceed: Parse each line into a list of cubes and bundle those lists into a brick.


/**
 * This class represents on cubic component of a [BrickOfSand]
 *
 * @property x This cube's x-coordinate.
 * @property y This cube's y-coordinate.
 * @property z This cube's z-coordinate.
 */
data class SandCube(val x: Int, val y: Int, val z: Int)

/**
 * This class represents a solid brick of sand
 *
 * I have no idea how the elves were able to get the sand to actually stay
 * in "brick" form. Christmas magic?
 *
 * @property cubes The cubes that, stuck together, comprise this brick of sand.
 */
data class BrickOfSand(val cubes: List<SandCube>) {
    companion object {
        /**
         * Parse a [BrickOfSand] from an input line
         *
         * @param str The input line representing a brick of sand.
         * @return The [BrickOfSand] represented by `str`.
         * @throws Exception When the input cannot be parsed.
         */
        fun fromString(str: String): BrickOfSand {
            val regex = Regex("""(\d),(\d),(\d+)~(\d),(\d),(\d+)""")
            val matches =
                regex.find(str)?.groupValues?.drop(1)?.map { it.toInt() }
                    ?: throw Exception("Could not parse $str into a [BrickOfSand]!")

            // Apparently you can't destructure 6 things at once from a list.
            val (x1, y1, z1) = matches
            val (x2, y2, z2) = matches.drop(3)

            // Depending on _which_ dimension changes from the first cube to the
            // last cube, produce a list of cubes from the front to the back
            // of this brick.
            val cubes = when {
                x2 > x1 -> (x1..x2).map { x -> SandCube(x, y1, z1) }
                x1 > x2 -> (x2..x1).map { x -> SandCube(x, y1, z1) }
                y2 > y1 -> (y1..y2).map { y -> SandCube(x1, y, z1) }
                y1 > y2 -> (y2..y1).map { y -> SandCube(x1, y, z1) }
                z2 > z1 -> (z1..z2).map { z -> SandCube(x1, y1, z) }
                z1 > z2 -> (z2..z1).map { z -> SandCube(x1, y1, z) }
                else -> listOf(SandCube(x1, y1, z1)) // Tiny brick!
            }

            return BrickOfSand(cubes)
        }
    }
}

class Day22(input: List<String>) {

    // Parse that list into bricks!
    private val parsed =
        input.filter { it.isNotEmpty() }.map(BrickOfSand::fromString)
        
}

Part One - Pile So High

So, let me get this straight. The problem here is that we have bricks of sand instead of, like, ya know, grains. And these bricks are magically stabilized so that they won’t tip off the top of a stack line normal physics demands? Has anyone considered that, perhaps, magically stabilizing the sand into bricks is the thing that we should stop doing? No, that’s just me? Ok, well, we’ve got the bricks now, let’s figure out what to do with them.


data class SandCube(val x: Int, val y: Int, val z: Int)

data class BrickOfSand(val cubes: List<SandCube>) {
    // companion object { ... }

    /**
     * Drop this brick by a given amount along the z-axis
     *
     * This is the function used to simulate dropping the brick from where it
     * starts to where it lands.
     *
     * @param amount How many steps along the z-axis to drop this brick.
     * @return A copy of this brick, dropped along the z-axis.
     */
    fun dropBy(amount: Int): BrickOfSand {
        val cubes = cubes.map { (x, y, z) -> SandCube(x, y, z - amount) }
        return BrickOfSand(cubes)
    }
}

/**
 * This class represents the pile of sand bricks
 *
 * The topographical map is mostly used for building up the pile of bricks,
 * although it was nice to be able to print it out to verify that bricks were
 * going where I thought they were.
 *
 * @property bricks A list of the bricks in the pile, in the order that the
 * bricks are added to the pile.
 * @property topoMap A 2D grid representing the height of the pile at each
 * x/y-coordinate.
 * @property spaceMap A mapping of each occupied cube to the brick that owns
 * that cube.
 */
data class SandBrickPile(
    val bricks: MutableList<BrickOfSand> = mutableListOf(),
    val topoMap: List<MutableList<Int>> = List(10) { MutableList(10) { 1 } },
    val spaceMap: MutableMap<SandCube, BrickOfSand> = mutableMapOf()
) {
    /**
     * Add a brick to the pile
     *
     * Drop a brick from it's starting position until it settles. Update the
     * list of bricks, topographic map, and spatial map of bricks to accommodate.
     *
     * @param brick The brick to drop
     */
    fun addBrick(brick: BrickOfSand) {
        // Figure out how far we can drop this brick by checking the height
        // of the topographic map underneath this falling brick. Then, drop
        // this brick by the minimum distance between a brick cube and the
        // tallest stack underneath.
        val dropToZ = brick.cubes.maxOf { (x, y, _) -> topoMap[y][x] }
        val dropByAmt = brick.cubes.minOf { (_, _, z) -> z - dropToZ }
        val droppedBrick = brick.dropBy(dropByAmt)

        // Add it to the list
        bricks.add(droppedBrick)

        // Update the topographical map
        droppedBrick.cubes.forEach { (x, y, z) -> topoMap[y][x] = z + 1 }

        // Update the spatial map
        droppedBrick.cubes.forEach { cube -> spaceMap[cube] = droppedBrick }
    }

    /**
     * Identify the bricks above the current brick (in contact)
     *
     * Get all the bricks resting on the brick being considered. A brick
     * that's long on the z-axis would include itself, so those need to
     * be filtered out.
     *
     * @param brick The brick to check for bricks above.
     * @return The list of bricks above the current brick.
     */
    private fun bricksAbove(brick: BrickOfSand) =
        brick.cubes.mapNotNull { (x, y, z) ->
            spaceMap[SandCube(x, y, z + 1)]
        }.filter { it != brick }

    /**
     * Identify the bricks below the current brick (in contact)
     *
     * Get all the bricks supporting the brick being considered. A brick
     * that's long on the z-axis would include itself, so those need to
     * be filtered out.
     *
     * @param brick The brick to check for bricks above.
     * @return The list of bricks above the current brick.
     */
    private fun bricksBelow(brick: BrickOfSand) =
        brick.cubes.mapNotNull { (x, y, z) ->
            spaceMap[SandCube(x, y, z - 1)]
        }.filter { it != brick }

    /**
     * Check to see if the target brick can be safely disintegrated
     *
     * A brick can be safely disintegrated if removing it wouldn't cause any
     * other bricks to fall and create a cascade of sandy blocks of doom.
     */
    fun canDisintegrate(brick: BrickOfSand): Boolean {
        // If all of the bricks above are resting on at least one other brick,
        // this brick can be disintegrated. The `all` function will return true
        // if `bricksAbove` is empty, as well.
        return bricksAbove(brick).all { brickAbove ->
            bricksBelow(brickAbove).any { brickBelow -> brickBelow != brick }
        }
    }
}

/**
 * Convert a list of sand bricks to a pile of sand bricks
 */
fun List<BrickOfSand>.pileUp(): SandBrickPile {
    val pile = SandBrickPile()
    // We need to sort the incoming bricks by the z axis so that we don't end
    // up trying to drop a brick inside a pile that's already piled up past where
    // that brick starts.
    sortedBy { brick -> brick.cubes.minOf { it.z } }.forEach { pile.addBrick(it) }
    return pile
}

class Day22(input: List<String>) {

    // private val parsed = ...

    // For part one, we pile up the bricks and see how many we could eliminate
    // without unsettling the pile.
    fun solvePart1(): Int {
        val pile = parsed.pileUp()
        return pile.bricks.count { brick -> pile.canDisintegrate(brick) }
    }
        
}

Ok, I’m feeling pretty good about this problem representation. This is nice.

Part Two - Another Brick In The Pile

Ok, now we’re about to have fun! It’s time to tip this pile over. Wait, no, it’s not? We’re just going to simulate what would happen if we knocked the pile over? Ah, man…


data class SandCube(val x: Int, val y: Int, val z: Int)

data class BrickOfSand(val cubes: List<SandCube>) {
    // companion object { ... }
    
    // fun dropBy(amount: Int): BrickOfSand { ... }
}

data class SandBrickPile(
    val bricks: MutableList<BrickOfSand> = mutableListOf(),
    val topoMap: List<MutableList<Int>> = List(10) { MutableList(10) { 1 } },
    val spaceMap: MutableMap<SandCube, BrickOfSand> = mutableMapOf()
) {
    // fun addBrick(brick: BrickOfSand) { ... }

    // private fun bricksAbove(brick: BrickOfSand) = ...

    // private fun bricksBelow(brick: BrickOfSand) = ...

    // fun canDisintegrate(brick: BrickOfSand): Boolean { ... }

    /**
     * Count the number of bricks that would fall if the target brick is removed
     *
     * @param keystone The brick being removed.
     */
    fun bricksDependingOn(keystone: BrickOfSand): Int {
        // We're going to do a depth-first search starting with the keystone
        // and working up the pile, adding bricks that will fall to our set
        // of fallen bricks.
        val stack = mutableListOf(keystone)
        val fallenBricks = mutableSetOf<BrickOfSand>()

        while (stack.isNotEmpty()) {
            // Get the current brick to check off the top of the stack. If
            // we've somehow already checked this one, skip it. Otherwise,
            // add it to the set of fallen bricks.
            val brick = stack.removeLast()
            if (brick in fallenBricks) continue
            fallenBricks.add(brick)

            // Now get all the bricks that will fall if `brick` is
            // removed
            val nowFalling =
                bricksAbove(brick).filter { brickAbove ->
                    bricksBelow(brickAbove).all { it in fallenBricks }
                }

            // For each brick that is now falling, add it to the stack for
            // future consideration, unless it's already been considered.
            for (newFallingBrick in nowFalling) {
                if (newFallingBrick in fallenBricks) continue
                stack.add(newFallingBrick)
            }
        }

        // Don't forget we don't count the original brick being removed
        return fallenBricks.size - 1
    }
}

// fun List<BrickOfSand>.pileUp(): SandBrickPile { ... }

class Day22(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Int { ... }

    // For part two, we pile up the bricks (again) and start dropping bricks to
    // see how many fall!
    fun solvePart2(): Int {
        val pile = parsed.pileUp()
        return pile.bricks.sumOf { brick -> pile.bricksDependingOn(brick) }
    }
        
}

There they go! Well, I’m visualizing what it would be like, at any rate.

Wrap Up

Today was a nice, implementation-heavy day, by which I mean it was a matter of correctly modeling the behaviors described as opposed to some neat math trick. In positive news, the same algorithm that solves the examples works on the input!!! Yay! This was a nice step-down in difficulty from yesterday, I think.

Advent of Code 2023 - Day 21

Thu, 21 Dec 2023 00:00:00 +0000

Day 21 - Step Counter

Find the problem description HERE.

The Input - Another Day, Another 2D Grid

Today, we have our old friends '.' and '#', along with the special guest 'S'! The grid represents a garden with passable spaces and impassable rocks. Let’s parse that grid!


/**
 * This enum represents one tile in the map of the garden
 */
enum class GardenMapTile {
    OPEN, ROCK, START;

    companion object {
        /**
         * Parse a [GardenMapTile] from a character
         *
         * @param char The character representing a [GardenMapTile].
         * @return A [GardenMapTile] represented by the input character.
         * @throws Exception When the character does not represent a [GardenMapTile].
         */
        fun fromChar(char: Char): GardenMapTile = when (char) {
            '.' -> OPEN
            '#' -> ROCK
            'S' -> START
            else -> throw Exception("Cannot parse $char to a [GardenMapTile]!")
        }
    }
}

/**
 * This class represents the map of the garden the elf wants to walk in
 *
 * @property grid The grid of tiles that comprise this garden.
 * @property start The elf's starting location for their walkabout.
 */
open class GardenMap(
    val grid: List<List<GardenMapTile>>,
    val start: Utils.Index2D
) {
    companion object {
        /**
         * Parse a [GardenMap] from the input
         *
         * @param input The grid of characters from the input file.
         * @return The [GardenMap] represented by the input file.
         * @throws Exception When the input cannot be parsed.
         */
        fun fromInput(input: List<List<Char>>): GardenMap {
            val grid = input.map { row -> row.map(GardenMapTile::fromChar) }

            // Search the grid for the first row/col index containing a
            // START tile.
            val start = grid.withIndex().flatMap { (rowIdx, row) ->
                row.withIndex().map { (colIdx, value) ->
                    Utils.Index2D(rowIdx, colIdx) to value
                }
            }.find { (_, tile) -> tile == GardenMapTile.START }?.first
                ?: throw Exception("Could not find starting tile!")

            return GardenMap(grid, start)
        }
    }

    // For pretty printing!
    override fun toString(): String = grid.joinToString("\n") { row ->
        row.joinToString("") { tile ->
            when (tile) {
                GardenMapTile.ROCK -> "#"
                GardenMapTile.OPEN -> "."
                GardenMapTile.START -> "S"
            }
        }
    }
}

class Day21(input: List<List<Char>>) {

    // We're old hands at parsing a grid of characters into a map of some sort.
    private val parsed = GardenMap.fromInput(input)
    
}

Now, let’s see what we need to do with this map…

Part One - Walking in a Winter Wonderland

So… turns out, there’s not really anything we need to be doing right now, so we’re going to help an active elf quantify their walk. I wonder if this elf knows the same trick as the ghost and plans to walk to all these reachable tiles simultaneously? Now that would be something to see! For now, though, we just need to identify which spaces in the map the elf can possibly land on after taking exactly 64 steps. Note that because the example uses a lower number of steps, the solution takes the number of allowed steps as a parameter.


/**
 * This enum represents one tile in the map of the garden
 */
enum class GardenMapTile {
    OPEN, ROCK, START;

    // companion object { ... }
}

open class GardenMap(
    val grid: List<List<GardenMapTile>>,
    val start: Utils.Index2D
) {
    // companion object { ... }

    val rows: Int get() = grid.size
    val cols: Int get() = grid.first().size
    val offsets = listOf(
        Utils.Offset2D(-1, 0),
        Utils.Offset2D(1, 0),
        Utils.Offset2D(0, -1),
        Utils.Offset2D(0, 1)
    )

    /**
     * Checks an index to ensure it is in the bounds of the map
     *
     * @param idx The index to check.
     * @return A boolean indicating whether the index is in bounds.
     */
    private fun inBounds(idx: Utils.Index2D): Boolean {
        val (row, col) = idx
        return row in 0..<rows && col in 0..<cols
    }

    // Indexing for the GardenMap
    open operator fun get(idx: Utils.Index2D) = grid[idx.row][idx.col]

    /**
     * Return the reachable neighboring indices of the given index
     *
     * @param idx The index to check for neighbors.
     * @return A list of neighboring indices that are reachable from `idx`. A
     * reachable idx is one that is in the bounds of the map and doesn't contain
     * a rock.
     */
    open fun neighborsOf(idx: Utils.Index2D) = offsets.map { idx + it }
        .filter { inBounds(it) && get(it) != GardenMapTile.ROCK }

    /**
     * Return the number of tiles that can be reached in a certain number of steps
     *
     * @param stepsAllowed The number of steps the elf will take.
     * @return The number of tiles that can be reached in exactly `stepsAllowed`
     * steps.
     */
    fun reachableTiles(stepsAllowed: Int): Int {

        // Mostly just a breadth-first search through the garden spaces.
        val queue = ArrayDeque(listOf(0 to start))
        val seen = mutableSetOf<Utils.Index2D>()

        // With the twist that we're keeping track of every tile we reach
        // and the number of steps it took to reach it.
        val visited = mutableListOf<Pair<Int, Utils.Index2D>>()

        while (queue.isNotEmpty()) {
            val (steps, tileIdx) = queue.removeLast()
            if (steps > stepsAllowed || seen.contains(tileIdx)) continue
            visited.add(steps to tileIdx)
            seen.add(tileIdx)

            for (neighborIdx in neighborsOf(tileIdx)) {
                if (seen.contains(neighborIdx)) continue
                queue.addFirst((steps + 1) to neighborIdx)
            }
        }

        // The tiles that are reachable in exactly `stepsAllowed` steps are
        // the tiles that we reach at the same parity as `stepsAllowed`, i.e.,
        // when `stepsAllowed` is even, the tiles reachable in an even number
        // of steps will be included. When `stepsAllowed` is odd, the tiles
        // reachable in an odd number of steps will be included. For our
        // purposes, 0 counts as an even number (so that the start will be
        // included for even numbers of steps).
        return visited.count { (idx, _) -> idx % 2 == stepsAllowed % 2 }
    }

}

class Day21(input: List<List<Char>>) {

    // private val parsed = ...

    // Walk the elf through the garden his desired number of steps and return
    // a count of all the tiles that can be landed on in exactly `stepsAllowed`
    // number of steps.
    fun solvePart1(stepsAllowed: Int): Int = parsed.reachableTiles(stepsAllowed)
    
}

Not too tough. A little breadth-first search with some pruning and we can directly find all the reachable spaces. Now for part two…

Part Two - Get To Steppin'

I’ll be honest, I really expected part two to involve some sort of quantum splitting of the elf along different paths. Instead, we just crank the number of steps to 11 and break the laws of space by wrapping the garden infinitely in all directions. Ugh. The worst part? We need math for this one. Double ugh!


/**
 * This enum represents one tile in the map of the garden
 */
enum class GardenMapTile {
    OPEN, ROCK, START;

    // companion object { ... }
}

open class GardenMap(
    val grid: List<List<GardenMapTile>>,
    val start: Utils.Index2D
) {
    // companion object { ... }

    val rows: Int get() = grid.size
    val cols: Int get() = grid.first().size
    val offsets = listOf(
        Utils.Offset2D(-1, 0),
        Utils.Offset2D(1, 0),
        Utils.Offset2D(0, -1),
        Utils.Offset2D(0, 1)
    )

    // private fun inBounds(idx: Utils.Index2D): Boolean { ... }

    // open operator fun get(idx: Utils.Index2D) = ...

    // open fun neighborsOf(idx: Utils.Index2D) = ...

    // fun reachableTiles(stepsAllowed: Int): Int { ... }

}

/**
 * This class represents the repeating garden map
 *
 * In part two, the map goes infinite! This subclass of [GardenMap] updates
 * some methods so that it can be treated as if it repeats infinitely in all
 * four directions.
 *
 * @property grid The grid of tiles that comprise this garden.
 * @property start The elf's starting location for their walkabout.
 */
class GardenMapInfinite(
    grid: List<List<GardenMapTile>>,
    start: Utils.Index2D
) : GardenMap(grid, start) {
    companion object {
        fun fromGardenMap(gardenMap: GardenMap): GardenMapInfinite {
            return GardenMapInfinite(gardenMap.grid, gardenMap.start)
        }
    }

    /**
     * Access an index in an infinite, repeating map
     *
     * To treat the _actually_ finite grid as an infinite map for indexing,
     * we need to wrap the indexes around the width and height of the grid.
     *
     * @param idx The index to fetch.
     * @return The map tile at that index.
     */
    override operator fun get(idx: Utils.Index2D): GardenMapTile {
        // Some fun with modulo to wrap the indices in both directions
        val rowIdx = (idx.row % rows + rows) % rows
        val colIdx = (idx.col % cols + cols) % cols
        return grid[rowIdx][colIdx]
    }

    /**
     * Get the neighbors of an index in an infinite garden
     *
     * The only change here is to remove the bounds-checking, because
     * an infinite garden is *boundless*!
     *
     * @param idx The index to check for neighbors.
     * @return A list of neighboring indices that are reachable from `idx`. A
     * reachable idx is one that doesn't contain a rock.
     */
    override fun neighborsOf(idx: Utils.Index2D) = offsets.map { idx + it }
        .filter { get(it) != GardenMapTile.ROCK }
}

class Day21(input: List<List<Char>>) {

    // private val parsed = ...

    // fun solvePart1(stepsAllowed: Int): Int = ...
    
    // Ugh, this is some funky (to me, at least) math.
    fun solvePart2(stepsAllowed: Int): Long {
        // Start by converting the garden map to a theoretically infinite tiling
        // of the original grid map.
        val map = GardenMapInfinite.fromGardenMap(parsed)

        /*
         And this is where it starts to get a bit...wonky. We can observe from
         the input that the number of steps the elf wants to take is a multiple
         of the grid size + (grid size // 2). The grid is 131 tiles square, so
         we can see that 26501365 = n * 131 + 65, with n = 202,300. We also
         note that, in the real input, there is a clear path from the start to
         each edge and each edge is clear all the way around. Additionally, the
         input forms a _diamond_ shape with a clear lane all the way around the
         manhattan distance of (grid size / 2) from the start. So, this means
         our zoomed out grid looks like:

                2....2
                ..11..
                ..11..
                2....2

        where the `1`'s represent the inner section of obstacles and the `2`'s
        represent the outer section of obstacles, which tiles to:

                2....22....22....22....22....2
                ..11....11....11....11....11..
                ..11....11....11....11....11..
                2....22....22....22....22....2
                2....22....22....22....22....2
                ..11....11....11....11....11..
                ..11....11....11....11....11..
                2....22....22....22....22....2
                2....22....22....22....22....2
                ..11....11....11....11....11..
                ..11....11....11....11....11..
                2....22....22....22....22....2
                2....22....22....22....22....2
                ..11....11....11....11....11..
                ..11....11....11....11....11..
                2....22....22....22....22....2
                2....22....22....22....22....2
                ..11....11....11....11....11..
                ..11....11....11....11....11..
                2....22....22....22....22....2

        So, without assuming that the `1` set of rocks and the `2` set of rocks
        are identical, we have alternating blocks of obstacles that form a
        repeating ring-like pattern around the center. We can then proceed on
        the assumption that these rings form the basis of a pattern in our
        output, like:

            - At (grid size / 2) steps, the elf's walking range encompasses the
              `1` set of obstacles in the center.
            - At (grid size / 2) + (grid size) steps, the elf's range now
              encompasses the entire first ring of obstacles, including 5 groups
              of `1`s and 4 groups of `2`s.
            - At (grid size / 2) + (grid size * 2), the elf's range now
              encompasses the first two rings of obstacles, including 13 groups
              of `1`'s and 12 groups of `2`'s.

        Because the number of obstacle groups included is scaling in some
        predictable fashion with an increase in number of steps by (grid size),
        we are able to manually find the first few results for the function
        steps -> reachable tiles and extrapolate the answer from there.
        */

        // Taking the first four results of steps -> reachable tiles for
        // step sizes at (grid size // 2), (grid size // 2) + (grid size),
        // (grid size // 2) + (grid size * 2), (grid size // 2) + (grid size * 3)...
        val stepIncrements = (0..3).map { incr ->
            (map.grid.size / 2) + (map.grid.size * incr)
        }
        val reachableTileCounts = stepIncrements.map { map.reachableTiles(it).toLong() }
            .toMutableList()

        /*
        For my input, I get [3755, 33494, 92811, 181706] for these first four
        counts of reachable tiles. The increase isn't linear, however, if we
        repeatedly take the differences between the values in sequence...

            [3755, 33494, 92811, 181706]
              [29739, 59317, 88895]
                  [29578, 29578]
                        [0]

        It's Day 9! Or, rather, it's a polynomial sequence. There's definitely
        math that can be done here to derive a formula for predicting the next
        values based on this, but for my own sanity, I'm going to use the same
        method from Day 9.
         */

        // Start by generating the lists of differences shown above.
        val diffs = mutableListOf(reachableTileCounts)
        while (diffs.last().last() > 0) {
            val diffDiffs =
                diffs.last().windowed(2).map { (prev, next) -> next - prev }
                    .toMutableList()
            diffs.add(diffDiffs)
        }
        diffs.reverse()

        // Calculate the number of times we need to predict the next value as
        // the number of times we can increase the number of steps by the
        // grid size, up to the desired number of steps, starting at
        // (grid size // 2), aka: 26501365 = n * 131 + 65, with n = 202,300.
        val numStepCycles = (stepsAllowed - (map.grid.size / 2)) / map.grid.size

        // Now, we use the same procedure from Day 9 to predict the next value
        // in our sequence `numStepCycles` times, and return the last predicted
        // value. Does this count as dynamic programming, I wonder?
        while (diffs.last().size <= numStepCycles) {
            for ((prev, next) in diffs.windowed(2)) {
                next.add(prev.last() + next.last())
            }
        }

        return diffs.last().last()
    }
}

I’m not going to lie, I needed a hint to get this one. I didn’t initially see the significance of the total number of steps or the fact that there was a clear path from the start to this entirely walk-able diamond shape within the pattern. With those two nuggets in hand, though, the rest of the solution (painfully) came together.

Wrap Up

Whew! This was a tough day. Not only did we have a cycle, but the cycle results were quadratic instead of linear, and it wasn’t immediately clear what we had a cycle of. I needed a few different hints in the right direction to finally wrap my head around what was happening here. On the positive side, being exposed to this kind of problem should help me be better able to spot similar situations in the future! On the negative side, I really dislike when the examples and the actual solution require different procedures to generate. Can’t win them all, I guess!

Advent of Code 2023 - Day 20

Wed, 20 Dec 2023 00:00:00 +0000

Day 20 - Pulse Propagation

Find the problem description HERE.

The Input - Modular Arithmetic

I’m back, baby!! After a couple days off from the blog (I still owe myself a blog post for Days 18 and 19), it’s time to get back in the saddle. And what an interesting input we have today. It’s not too complicated, but I think I may have over-complicated it a bit with my choice of data structure. It’s done now, though, and it works, so I’m probably not going to change it.


/**
 * This enum represents the two kinds of pulses
 */
enum class PulseKind {
    LOW, HIGH
}

/**
 * This class represents a pulse sent through the [ModuleArray]
 *
 * @property source The label of the module sending the pulse.
 * @property destination The label of the module to receive the pulse.
 * @property kind The kind of pulse being sent.
 */
data class Pulse(
    val source: String,
    val destination: String,
    val kind: PulseKind
)

/**
 * This class serves as the base class for all modules
 *
 * @property label The label for this module, giving its name.
 * @property destinations A list of labels for modules to send pulses to.
 */
abstract class AbstractModule(
    val label: String,
    val destinations: List<String>
) {
    /**
     * Receive a pulse and send pulses to all destination modules
     *
     * This function is responsible for this module receiving a pulse,
     * processing it in some way, then sending resulting pulses to all of
     * this module's destinations.
     *
     * @param pulse The pulse sent to this module.
     * @return The list of pulses sent by this module.
     */
    abstract fun relay(pulse: Pulse): List<Pulse>
}

/**
 * This class represents the Broadcaster module
 *
 * Broadcaster modules only receive pulses from the "button" and forward that
 * pulse on to its destinations.
 *
 * @property label The label for this module, giving its name.
 * @property destinations A list of labels for modules to send pulses to.
 */
class Broadcaster(label: String, destinations: List<String>) :
    AbstractModule(label, destinations) {
    // TODO: Implement the `relay` function
}

/**
 * This class represents the FlipFlop module
 *
 * The FlipFlop module maintains an inner ON or OFF state, which affects
 * how the module responds to pulses. FlipFlop modules ignore HIGH pulses.
 * A LOW pulse will cause the FlipFlop's state to toggle from ON to OFF or
 * from OFF to ON. When the FlipFlop toggles ON, it sends a HIGH pulse to
 * all destinations. When the FlipFlop toggles OFF, it sends a LOW pulse to
 * all destinations.
 *
 * @property label The label for this module, giving its name.
 * @property destinations A list of labels for modules to send pulses to.
 * @property state The internal state of the FlipFlop.
 */
class FlipFlop(
    label: String,
    destinations: List<String>,
    private var state: FlipFlopState = FlipFlopState.OFF
) : AbstractModule(label, destinations) {
    // TODO: Implement the `relay` function
}

/**
 * This class represents the Conjuction module
 *
 * The Conjunction module maintains a memory of the last pulse kind received
 * from each of its inputs. When receiving a pulse, first the Conjunction
 * updates its memory. If all pulses in memory are HIGH pulses, the Conjunction
 * emits a LOW pulse. Otherwise, it emits a HIGH pulse.
 *
 * @property label The label for this module, giving its name.
 * @property destinations A list of labels for modules to send pulses to.
 * @property memory The internal state of the Conjunction, tracking the kind of
 * pulse last received from all its inputs. Defaults to LOW for all inputs.
 */
class Conjunction(
    label: String,
    destinations: List<String>,
    private val memory: MutableMap<String, PulseKind> = mutableMapOf()
) : AbstractModule(label, destinations) {
    // TODO: Implement the `relay` function

    // Used to register an input to this module.
    fun registerInput(label: String) {
        memory[label] = PulseKind.LOW
    }
}

/**
 * This class represents the full array of modules
 *
 * @property modules A map of module labels to [AbstractModule]s.
 */
data class ModuleArray(val modules: Map<String, AbstractModule>) {
    companion object {
        /**
         * Parse a [ModuleArray] from the lines of the input file
         *
         * Each line in the input represents the relationship between a sender
         * module and its receivers. This function parses those lines into
         * [AbstractModule]s and maps the labels of the modules to the
         * [AbstractModule]s they represent.
         *
         * @param input Lines from the input file.
         * @return The [ModuleArray] represented by the input.
         * @throws Exception When a line from the input cannot be parsed.
         */
        fun fromInput(input: List<String>): ModuleArray {
            val modules = mutableMapOf<String, AbstractModule>()
            for (line in input) {
                // Get the strings left and right of the " -> "
                val (leftStr, rightStr) = line.split(" -> ")

                // Split the destination labels on commas
                val destinations = rightStr.split(", ")

                // Produce the appropriate kind of [AbstractModule] based on the
                // string to the left of the " -> ".
                val (label, module) = when {
                    leftStr == "broadcaster" -> (leftStr
                            to Broadcaster(leftStr, destinations))

                    leftStr.startsWith("%") -> {
                        val label = leftStr.removePrefix("%")
                        label to FlipFlop(label, destinations)
                    }

                    leftStr.startsWith("&") -> {
                        val label = leftStr.removePrefix("&")
                        label to Conjunction(label, destinations)
                    }

                    else -> throw Exception("Cannot parse $line to a module mapping!")
                }
                modules[label] = module
            }

            // At this point, the [Conjunction] modules don't know what their
            // inputs are, so we loop through the mapping of modules and
            // register each input to a Conjunction module with the
            // receiving Conjunction module.
            for ((inputLabel, module) in modules) {
                for (destination in module.destinations) {
                    val destinationModule = modules[destination]
                    if (destinationModule !is Conjunction) continue
                    destinationModule.registerInput(inputLabel)
                }
            }

            return ModuleArray(modules)
        }
    }
}

class Day20(val input: List<String>) {

    // Parse the input file into an array of [AbstractModule]s. Use
    // a calculated value here so that we get a fresh copy of the
    // parsed input each time this value is fetched.
    private val parsed: ModuleArray get() = ModuleArray.fromInput(input)
    
}

Most of the problem is solved at this point - we have all the data structures in place and have even specified some of the methods we need. Now we just need to fill in the logic for propagating pulses through our ModuleArray.

Part One - Push the Button!

Ah man, I kind of wish we got to push the button 1,000 times! I bet it was a big, red button too. Probably had a satisfying click or ka-chunk when it was pressed too. Oh well, at least we get to map the pulses through our array of modules. In our parsing step, we set up a lot of what we need, so let’s fill in the logic.


// enum class PulseKind { ... }

// data class Pulse( ... )

abstract class AbstractModule(
    val label: String,
    val destinations: List<String>
) {
    abstract fun relay(pulse: Pulse): List<Pulse>
}

class Broadcaster(label: String, destinations: List<String>) :
    AbstractModule(label, destinations) {
    
    // Just forward received pulses
    override fun relay(pulse: Pulse) =
        destinations.map { Pulse(label, it, PulseKind.LOW) }
}

class FlipFlop(
    label: String,
    destinations: List<String>,
    private var state: FlipFlopState = FlipFlopState.OFF
) : AbstractModule(label, destinations) {
    enum class FlipFlopState { ON, OFF }
    
    // It's FlipFlop logic!
    override fun relay(pulse: Pulse) = when (pulse.kind) {
        PulseKind.HIGH -> listOf()
        PulseKind.LOW -> when (state) {
            FlipFlopState.OFF -> {
                state = FlipFlopState.ON
                destinations.map { Pulse(label, it, PulseKind.HIGH) }
            }

            FlipFlopState.ON -> {
                state = FlipFlopState.OFF
                destinations.map { Pulse(label, it, PulseKind.LOW) }
            }
        }
    }
}

class Conjunction(
    label: String,
    destinations: List<String>,
    private val memory: MutableMap<String, PulseKind> = mutableMapOf()
) : AbstractModule(label, destinations) {

    // It's Conjunction logic!
    override fun relay(pulse: Pulse): List<Pulse> {
        // First update the memory for the input
        memory[pulse.source] = pulse.kind

        // Then determine the kind of pulse to send
        val sendKind = if (memory.values.all { it == PulseKind.HIGH }) {
            PulseKind.LOW
        } else {
            PulseKind.HIGH
        }

        return destinations.map { Pulse(label, it, sendKind) }
    }

    // Used to register an input to this module.
    fun registerInput(label: String) {
        memory[label] = PulseKind.LOW
    }
}

data class ModuleArray(val modules: Map<String, AbstractModule>) {
    // companion object { ... }

    /**
     * Send a pulse through the [ModuleArray]
     *
     * Since each pulse is equipped with the name of the sender and receiver,
     * we can pass it directly to the [ModuleArray] and route it to its
     * intended receiver. If the named destination isn't in the module array,
     * we can just ignore that pulse.
     *
     * @param pulse The [Pulse] to route through the [ModuleArray].
     * @return The list of pulses that result from routing the input pulse to
     * its intended destination.
     */
    private fun route(pulse: Pulse): List<Pulse> {
        val destinationModule = modules[pulse.destination]
            ?: return listOf()
        return destinationModule.relay(pulse)
    }

    /**
     * Push. The. Button!!!
     *
     * Simulates pushing the button module one time, which sends a LOW pulse to
     * the [Broadcaster] module. The resulting pulses are created and consumed
     * until no more pulses are generated. Returns a list of all pulses sent
     * through the [ModuleArray] as a result of pushing the button.
     *
     * @return A list of pulses generated by pushing the button.
     */
    fun pushTheButton(): List<Pulse> {
        val initialPulse = Pulse("button", "broadcaster", PulseKind.LOW)
        val queue = ArrayDeque(listOf(initialPulse))
        val sentPulses = mutableListOf<Pulse>()

        while (queue.isNotEmpty()) {
            val pulse = queue.removeLast()
            sentPulses.add(pulse)
            for (nextPulse in route(pulse)) queue.addFirst(nextPulse)
        }

        return sentPulses
    }
}

class Day20(val input: List<String>) {

    // private val parsed: ModuleArray get() = ...

    // In part one, we push the button, sending pulses through the array
    // of modules and count the kinds of pulses that propagate through.
    fun solvePart1(): Int {
        var lowPulses = 0
        var highPulses = 0
        val moduleArray = parsed
        repeat(1000) {
            moduleArray.pushTheButton().forEach { pulse ->
                when (pulse.kind) {
                    PulseKind.LOW -> lowPulses += 1
                    PulseKind.HIGH -> highPulses += 1
                }
            }
        }
        return lowPulses * highPulses
    }
}

Man, that’s satisfying! The necessity for having a Conjunction be aware of the origin of pulse’s it receives makes things a little awkward. I feel like I’m passing around too much information with each pulse, but it works, so I’ll take my star and move on.

Part Two - Conjunction Junction, What’s Your Function?

I feel like this was on purpose, but it turns out that a junction of Conjunction modules actually is the key to solving part two today. I’m not normally a big fan of the “look at your input carefully” puzzle solutions, and that goes for today as well. Part two is a variation on the “if the number of iterations is astronomical, look for a cycle” approach to a solution.


// enum class PulseKind { ... }

// data class Pulse( ... )

// abstract class AbstractModule( ... ) { ... }

// class Broadcaster( ... ) : AbstractModule( ...) { ... }

// class FlipFlop( ... ) : AbstractModule( ...) { ... }

// class Conjunction( ... ) : AbstractModule( ...) { ... }

data class ModuleArray(val modules: Map<String, AbstractModule>) {
    // companion object { ... }

    // private fun route(pulse: Pulse): List<Pulse> { ... }

    // fun pushTheButton(): List<Pulse> { ... }
    
    
    /**
     * Find the cycle length of a single Conjunction module
     *
     * In part two, we need to identify the periodicity with which several
     * [Conjunction] modules send a HIGH signal. Given the label for a
     * conjunction module, simulate pushing the button while keeping an eye
     * on that conjunction module, returning the number of button pushes it
     * regularly takes to produce a HIGH pulse.
     *
     * @param label The label for the [Conjunction] module to monitor.
     * @return The number of button presses in the cycle that produces a HIGH
     * pulse from the monitored [Conjunction] module.
     */
    fun findConjunctionModuleCycleLength(label: String): Long {
        // Start by making sure we've actually got a [Conjunction] module that's
        // in the [ModuleArray].
        val checkedModule =
            modules[label] ?: throw Exception("There is no $label module!")
        require(checkedModule is Conjunction) { throw Exception("$checkedModule is not a Conjunction!") }

        // Continue by pushing the button until the indicated module sends a LOW
        // signal. I included this part in case there were some button pushes
        // needed to get to the point where the cycle starts. In that case, I
        // would have needed to account for those pushes later. Turns out, that
        // wasn't the case, but I left this in to explain my reasoning.
        var isPrimed = false
        while (!isPrimed) {
            isPrimed =
                pushTheButton().any { (s, _, k) -> s == label && k == PulseKind.HIGH }
        }

        // Starting at the state right after the monitored conjunction module
        // sent a HIGH pulse, we again push the button repeatedly until the
        // monitored module sends another HIGH pulse. This is the presumed
        // cycle length.
        var cycleLength = 1L
        while (!pushTheButton().any { (s, _, k) -> s == label && k == PulseKind.HIGH }) {
            cycleLength += 1
        }

        // To confirm this cycle length is stable, we run the cycle one more time
        // and compare this count to the previous count. If the two cycle counts
        // weren't equal, we'd need to figure out something else to solve this
        // puzzle.
        var confirmationCycleLength = 1L
        while (!pushTheButton().any { (s, _, k) -> s == label && k == PulseKind.HIGH }) {
            confirmationCycleLength += 1
        }

        // I wasn't initially convinced that the only state I needed to keep up with
        // was the output from the module of interest. If I wasn't able to get
        // a consistent cycle length just checking the output of the module under
        // review, I'd have needed to try something else.
        require(cycleLength == confirmationCycleLength) {
            throw Exception("Need more info to calculate cycle length for $label!")
        }

        return cycleLength
    }
}

class Day20(val input: List<String>) {

    // private val parsed: ModuleArray get() = ...

    // fun solvePart1(): Int { ... }
    
    /*
    My input includes the following lines:
          &hj -> rx
          &ks -> hj
          &jf -> hj
          &qs -> hj
          &zk -> hj

    So, what does this mean? For one, it means that there is a single
    Conjunction module `hj` attached to `rx` with four other Conjunction
    modules feeding into it. That means a _lot_ of button presses are likely
    needed to have all four of those Conjunction modules coincide to send a
    HIGH pulse to `hj` at the same time. And, since it's Advent of Code and
    we're likely dealing with a huge number, let's look for cycles!
    */
    fun solvePart2(): Long {
        // Start by finding the input that feeds into 'rx'
        val rxInput = parsed.modules.asSequence()
            .filter { (_, module) -> "rx" in module.destinations }
            .map { (label, _) -> label }.single()

        // Then get the cycle length for all the inputs that feed into the `rxInput`.
        // The least common multiple of those cycle lengths is the number of
        // button pushes needed to get them to all sync up.
        return parsed.modules.asSequence()
            .filter { (_, module) -> rxInput in module.destinations }
            .map { (label, _) -> parsed.findConjunctionModuleCycleLength(label) }
            .toList()
            .lcm()
    }
}

My big complaint here is that I can’t be certain whether or not this solution is general enough to apply to all valid inputs. I know it’s not general enough for every possible configuration of a ModuleArray, but I can’t be sure it will solve the puzzle for anyone else, either.

The Wrap Up

It feels good to be back! Granted, spending the last couple of days traveling with my family was also nice, so no complaints here. My main gripe is possible not feeling like going back and writing blog posts for the two days I’ve missed, but that’s just me being lazy. Today is the first day where I’ve felt like taking the OO approach with sub-classes actually helped me get to the solution, which is something else to be happy about. All in all, a good day. Only five left!

Advent of Code 2023 - Day 19

Tue, 19 Dec 2023 00:00:00 +0000

Day 19 - Aplenty

Find the problem description HERE.

The Input - Rules are Rules

Now that the parts are flowing again, we need to help the elves sort them and determine which parts are acceptable for use. Thankfully, they’ve gone to the trouble of writing down their workflows and criteria for checking, approving, and/or rejecting parts. Now, we just need to model those workflows!

/**
 * This enum represents the four types of part ratings
 */
enum class RatingCategory {
    X, M, A, S;

    companion object {
        /**
         * Parse a [RatingCategory] from a string
         *
         * @param str The string to parse the rating category from.
         * @return A [RatingCategory] parsed from a string.
         * @throws Exception When the string cannot be parsed.
         */
        fun fromString(str: String): RatingCategory = when (str) {
            "x" -> X
            "m" -> M
            "a" -> A
            "s" -> S
            else -> throw Exception("There is no category for $str!")
        }
    }
}

/**
 * This class represents the different possible results from applying a [Rule]
 *
 * Each [Rule] in a [Workflow] has one of three possible outcomes:
 * - The part is accepted.
 * - The part is rejected.
 * - The part is transferred to another workflow.
 */
sealed class RuleResult {
    // This variant represents a transfer to another workflow and includes
    // the label of the new workflow as a property.
    class Transfer(val label: String) : RuleResult()
    data object Approve : RuleResult()
    data object Reject : RuleResult()

    companion object {
        /**
         * Parse a [RuleResult] from a string
         *
         * @param str The string to parse.
         * @return A [RuleResult] parsed from the String.
         */
        fun fromString(str: String) = when (str) {
            "A" -> Approve
            "R" -> Reject
            else -> Transfer(str)
        }
    }
}

/**
 * This enum represents the kind of comparison used by a [Rule]
 *
 * Each [Rule] compares some [RatingCategory] of a [MachinePart] to a constant
 * value when determining whether the part passes that rule or gets forwarded
 * further along the [Workflow].
 */
enum class ComparisonKind {
    GREATER_THAN, LESS_THAN;

    companion object {
        /**
         * Parses a [ComparisonKind] from a string
         *
         * @param str The string to parse a comparison kind from.
         * @return The [ComparisonKind] represented by the input string.
         * @throws Exception When the input string cannot be parsed.
         */
        fun fromString(str: String) = when (str) {
            ">" -> GREATER_THAN
            "<" -> LESS_THAN
            else -> throw Exception("Cannot convert $str to a [ComparisonType]!")
        }
    }
}

/**
 * This class represents a rule for checking a [MachinePart]
 *
 * Each step (except the last) in a [Workflow] consists of a rule that tests
 * a [MachinePart] to see if it is approved, rejected, passed to another
 * [Workflow], or forwarded further along the current [Workflow].
 *
 * @property category Which rating from the [MachinePart] is being checked?
 * @property result The [RuleResult] of successfully applying this rule.
 * @property comparison The kind of comparison to use when applying this rule.
 * @property compareTo The constant value to compare the part's rating to.
 */
data class Rule(
    val category: RatingCategory,
    val result: RuleResult,
    val comparison: ComparisonKind,
    val compareTo: Int,
) {
    companion object {
        /**
         * Parse a [Rule] from a string
         *
         * @param str The string to parse the rule from.
         * @return The [Rule] represented by the parsed string.
         * @throws Exception when the string cannot be parsed.
         */
        fun fromString(str: String): Rule {
            // Use this regular expression to match against the string
            // and break it up into its constituent parts.
            val regex = Regex("""([xmas])([><])(\d+):(\w+)""")
            val matches = regex.find(str)
            val (catStr, opStr, valStr, resStr) = matches?.destructured
                ?: throw Exception("Could not parse $str into a [Rule]!")

            // Then, take each string and parse it individually.
            val testCategory = RatingCategory.fromString(catStr)
            val result = RuleResult.fromString(resStr)
            val comparison = ComparisonKind.fromString(opStr)
            val compareTo = valStr.toInt()

            return Rule(testCategory, result, comparison, compareTo)
        }
    }
}

/**
 * This class represents a workflow
 *
 * Each workflow consists of a list of sequential rules to check a [MachinePart]
 * against and a final `default` action to take if the part doesn't satisfy
 * any of the `rules`.
 *
 * @property rules The ordered list of rules to check a [MachinePart] against.
 * @property default The default [RuleResult] to apply if no rule is satisfied.
 */
data class Workflow(
    val rules: List<Rule>,
    val default: RuleResult
)

/**
 * This class represents the full set of all [Workflow]s
 *
 * @property workflows A mapping of workflow label to workflow
 */
data class WorkflowSet(val workflows: Map<String, Workflow>) {
    companion object {
        /**
         * Parse a [WorkflowSet] from a list of lines from the input
         *
         * @param lines The lines from the input that define workflows.
         * @return The parsed [WorkflowSet].
         * @throws Exception When a line from the input cannot be parsed.
         */
        fun fromInput(lines: List<String>): WorkflowSet {
            val regex = Regex("""(\w+)\{(.*)\}""")
            val workflows = lines.associate { line ->
                val matches = regex.find(line)
                val (label, rulesStr) = matches?.destructured
                    ?: throw Exception("Cannot parse a workflow from $line!")
                val rulesStrList = rulesStr.split(",").toMutableList()
                val default = RuleResult.fromString(rulesStrList.removeLast())
                val rules = rulesStrList.map(Rule::fromString)
                label to Workflow(rules, default)
            }
            return WorkflowSet(workflows)
        }
    }
}

/**
 * This class represents a machine part
 *
 * Yes. The rating abbreviations are X-MAS. I saw that too.
 *
 * @property x The degree of coolness of the part.
 * @property m The musicality of the part.
 * @property a The extent of the part's aerodynamic qualities.
 * @property s SHININESS!!!!!
 */
data class MachinePart(val x: Int, val m: Int, val a: Int, val s: Int) {
    companion object {
        /**
         * Parse a [MachinePart] from a string
         *
         * @param str The string representation of a machine part.
         * @return The [MachinePart] represented by the string.
         * @throws Exception If the string does not represent a [MachinePart].
         */
        fun fromString(str: String): MachinePart {
            val regex = Regex("""\{x=(\d+),m=(\d+),a=(\d+),s=(\d+)\}""")
            val matches = regex.find(str)
            val (xStr, mStr, aStr, sStr) = matches?.destructured
                ?: throw Exception("$str cannot be parsed to a [MachinePart]!")
            return MachinePart(
                xStr.toInt(),
                mStr.toInt(),
                aStr.toInt(),
                sStr.toInt()
            )
        }
    }

    // It's kind of nice to be able to index a part by the rating enum.
    operator fun get(category: RatingCategory) = when (category) {
        RatingCategory.X -> x
        RatingCategory.M -> m
        RatingCategory.A -> a
        RatingCategory.S -> s
    }

    val totalRating: Int get() = x + m + a + s
}

class Day19(val input: List<List<String>>) {

    // I feel like _I_ needed a workflow for the amount of modeling I did on
    // today's puzzle. It turned out well, though!
    private val parsed: Pair<WorkflowSet, List<MachinePart>>
        get() {
            val (workflowLines, machinePartLines) = input
            val workflowSet = WorkflowSet.fromInput(workflowLines)
            val machineParts = machinePartLines.map(MachinePart::fromString)
            return workflowSet to machineParts
        }
}

There’s a lot of specificity in this setup, but I think it sets us up nicely to solve the puzzle.

Part One - Pass or Fail

In part one, we take our list of machine parts and run them through the specified workflows, reporting some information about the parts that pass inspection.

enum class RatingCategory {
    X, M, A, S;

    // companion object { ... }
}

sealed class RuleResult {
    class Transfer(val label: String) : RuleResult()
    data object Approve : RuleResult()
    data object Reject : RuleResult()

    // companion object { ... }
}

enum class ComparisonKind {
    GREATER_THAN, LESS_THAN;

    // companion object { ... }
}

data class Rule(
    val category: RatingCategory,
    val result: RuleResult,
    val comparison: ComparisonKind,
    val compareTo: Int,
) {
    // companion object { ... }

    /**
     * Check a [MachinePart] to see if it satisfies this [Rule]
     *
     * @param part The [MachinePart] to check.
     * @return A boolean indicating whether the part satisfies this rule.
     */
    fun passes(part: MachinePart) = when (comparison) {
        ComparisonKind.GREATER_THAN -> part[category] > compareTo
        ComparisonKind.LESS_THAN -> part[category] < compareTo
    }
}

data class Workflow(
    val rules: List<Rule>,
    val default: RuleResult
) {
    /**
     * Process a [MachinePart] through this [Workflow]
     *
     * Check the part against each rule, in order. If the part satisfies any
     * rule, return the result. Otherwise, return the default result.
     *
     * @param part The [MachinePart] to check.
     * @return The result of the workflow.
     */
    fun processPart(part: MachinePart): RuleResult {
        for (rule in rules) if (rule.passes(part)) return rule.result
        return default
    }
}

data class WorkflowSet(val workflows: Map<String, Workflow>) {
    // companion object { ... }

    /**
     * Process a single part through the various workflows
     *
     * Each part starts at the workflow labelled "in". From there, it is
     * processed by one or more [Workflow]s until it is ultimately accepted
     * or rejected.
     *
     * @param part The [MachinePart] to process.
     * @return The result of processing this part.
     * @throws Exception When attempting to pass a part to a [Workflow] that's
     * not in the [WorkflowSet]. This should not happen with well-formed input.
     */
    fun processPart(part: MachinePart): RuleResult {
        var result: RuleResult = RuleResult.Transfer("in")

        // So long as the result of processing the part through a workflow
        // is to transfer it, we keep passing the part to the next workflow
        // and processing. This loop will end once the part is either
        // accepted or rejected.
        while (result is RuleResult.Transfer) {
            result = workflows[result.label]?.processPart(part)
                ?: throw Exception("There is no workflow labeled ${result.label}")
        }
        return result
    }
}


data class MachinePart(val x: Int, val m: Int, val a: Int, val s: Int) {
    // companion object { ... }

    // operator fun get(category: RatingCategory) = ...

    // val totalRating: Int get() = ...
}

class Day19(val input: List<List<String>>) {

    // private val parsed: Pair<WorkflowSet, List<MachinePart>> get() { ... }

    // In part one, we check all the given machine parts against a verification
    // workflow and tally the ratings of the approved parts.
    fun solvePart1(): Int {
        val (workflows, parts) = parsed
        return parts.filter { part -> workflows.processPart(part) is RuleResult.Approve }
            .sumOf { it.totalRating }
    }
}

As is often the case in part one, modeling and simulating the process described in the puzzle input gets us to where we need to be. Again, we have bits of functionality spread out amongst various classes, but it all nestles pretty neatly into where it belongs.

Part Two - Greater Than the Sum of Our Parts

In part two, the elves want to know how many different combinations of part ratings can possibly be passed through their workflow. A reasonable request, for sure, with an unreasonably large answer, at least according to the example we have. As we’ve seen a couple of times this year already, there are a couple of common ways to deal with very large numbers: cycles and ranges. This seems more like a “range” kind of problem to me…

enum class RatingCategory {
    X, M, A, S;

    // companion object { ... }
}

sealed class RuleResult {
    class Transfer(val label: String) : RuleResult()
    data object Approve : RuleResult()
    data object Reject : RuleResult()

    // companion object { ... }
}

enum class ComparisonKind {
    GREATER_THAN, LESS_THAN;

    // companion object { ... }
}

data class Rule(
    val category: RatingCategory,
    val result: RuleResult,
    val comparison: ComparisonKind,
    val compareTo: Int,
) {
    // companion object { ... }

    // fun passes(part: MachinePart) = when (comparison) { ... }
}

data class Workflow(
    val rules: List<Rule>,
    val default: RuleResult
) {
    // fun processPart(part: MachinePart): RuleResult { ... }

    /**
     * Process a range of machine parts
     *
     * In part two, we no longer care about specific parts and are concerned
     * instead with determining how many possible part combinations could pass
     * through our full [WorkflowSet]. To process a [MachinePartRange], instead
     * of using a [Rule] to determine if the specific values pass, we use that
     * [Rule] to split the [MachinePartRange] into parts that do and do not
     * satisfy the rule. The range that does not satisfy the rule is processed
     * further in the [Workflow] while the range that _does_ satisfy the
     * rule is added to the output of this function along with the associated
     * [RuleResult] of satisfying that [Rule].
     *
     * @param partRange A range of possible machine part ratings.
     * @return A list of machine part ranges and the associated action for each.
     */
    fun processPartRange(partRange: MachinePartRange): List<Pair<MachinePartRange, RuleResult>> {

        // This function will output a list of machine part ranges with the
        // action to take on that range based on whether that part
        // satisfied one of the rules in this workflow.
        val results = mutableListOf<Pair<MachinePartRange, RuleResult>>()
        var currentRange = partRange

        for (rule in rules) {
            currentRange = when (rule.comparison) {
                // When the comparison is "greater than", the part of the range
                // greater than the comparison constant is said to have
                // satisfied the rule and is added to the output. The part of
                // the range that fails the rule is forwarded to the next
                // rule in the workflow.
                ComparisonKind.GREATER_THAN -> {
                    val (partRange1, partRange2) = currentRange.splitAt(
                        rule.category,
                        rule.compareTo + 1
                    )
                    results.add(partRange2 to rule.result)
                    partRange1
                }

                // The same thing in reverse is true for the "less than"
                // comparison.
                ComparisonKind.LESS_THAN -> {
                    val (partRange1, partRange2) = currentRange.splitAt(
                        rule.category,
                        rule.compareTo
                    )
                    results.add(partRange1 to rule.result)
                    partRange2
                }
            }
        }

        // Any range of parts left over didn't satisfy _any_ rules, and so
        // it gets added to the results with the default [RuleResult]
        results.add(currentRange to default)

        return results
    }
}

data class WorkflowSet(val workflows: Map<String, Workflow>) {
    // companion object { ... }

    // fun processPart(part: MachinePart): RuleResult { ... }

    /**
     * Find all part ranges that can be approved
     *
     * In part two, we need to identify all the possible combinations of
     * part ratings that can be approved. To do _that_, we need to identify
     * all the _ranges_ of part ratings that ultimately reach the "approved"
     * result.
     *
     * @return A list of [MachinePartRange]s that are ultimately approved.
     * @throws Exception When attempting to pass a part to a [Workflow] that's
     * not in the [WorkflowSet]. This should not happen with well-formed input.
     */
    fun findAllApprovedPartRanges(): List<MachinePartRange> {
        // These are the ranges we'll return at the end
        val approvedRanges = mutableListOf<MachinePartRange>()

        // We'll be doing a variant of a breadth-first search through the
        // workflows. There's no need to check for whether we're in a
        // loop this time, all the workflows flow from start to finish.
        // We start with the full range of 1..4000 in all four ratings
        // at the "in" workflow.
        val queue = ArrayDeque<Pair<MachinePartRange, RuleResult>>(
            listOf(MachinePartRange() to RuleResult.Transfer("in"))
        )

        // Until we've processed all ranges through all workflows...
        while (queue.isNotEmpty()) {
            val (partRange, ruleResult) = queue.removeLast()

            // If the range of parts is approved, it gets added to the results.
            // If it's rejected, we skip it. If it's transferred, then we process
            // it through the target workflow, yielding a list of <range/result>
            // pairings. Each of those pairs is added to the queue for
            // further processing.
            when (ruleResult) {
                is RuleResult.Approve -> approvedRanges.add(partRange)
                is RuleResult.Reject -> continue
                is RuleResult.Transfer -> {
                    val workflow = workflows[ruleResult.label]
                        ?: throw Exception("There is no workflow labeled ${ruleResult.label}!")
                    for (rangeResultPair in workflow.processPartRange(partRange)) {
                        queue.addFirst(rangeResultPair)
                    }
                }
            }
        }

        return approvedRanges
    }
}


// data class MachinePart(val x: Int, val m: Int, val a: Int, val s: Int) { ... }


/**
 * This class represents a range of machine part ratings
 *
 * There are ultimately four dimensions of [MachinePart] rating. This class
 * represents a four-fold range of possible part ratings.
 *
 * @property x The range of the degree of coolness of the parts.
 * @property m The range of musicality of the parts.
 * @property a The range of the parts' aerodynamic qualities.
 * @property s The range from -shiny- to *!*!SHINY!*!*.
 */
data class MachinePartRange(
    val x: IntRange = 1..4000,
    val m: IntRange = 1..4000,
    val a: IntRange = 1..4000,
    val s: IntRange = 1..4000,
) {
    // Useful here, too.
    operator fun get(category: RatingCategory) = when (category) {
        RatingCategory.X -> x
        RatingCategory.M -> m
        RatingCategory.A -> a
        RatingCategory.S -> s
    }

    // Calculate and return the total number of individual combinations
    // represented by this [MachinePartRange]
    val totalCombinations: Long
        get() {
            val xCount = ((x.last - x.first) + 1).toLong()
            val mCount = ((m.last - m.first) + 1).toLong()
            val aCount = ((a.last - a.first) + 1).toLong()
            val sCount = ((s.last - s.first) + 1).toLong()
            return xCount * mCount * aCount * sCount
        }

    /**
     * Split a [MachinePartRange] around a given rating and value
     *
     * Any time a [MachinePartRange] is tested against a rule (at least, in
     * my input), a part of the range passes the test and another part fails.
     * This function splits the range into these two parts.
     *
     * @param category The rating range to be split.
     * @param value The numeric value to split around.
     * @return A pair of [MachinePartRange]s split on `rating` around `value`.
     */
    fun splitAt(
        category: RatingCategory,
        value: Int
    ): Pair<MachinePartRange, MachinePartRange> {
        // First we verify that the value actually falls within the rating range.
        val range = this[category]
        require(value in range) {
            throw Exception("Cannot split the range $range around $value!")
        }

        // Then we split the range. The split will always exclude the given
        // value from the bottom range and include it in the top range.
        val range1 = this[category].first until value
        val range2 = value..this[category].last

        // Return a pair of [MachinePartRange]s with the new range
        // values on the correct rating.
        return when (category) {
            RatingCategory.X -> (MachinePartRange(range1, m, a, s)
                    to MachinePartRange(range2, m, a, s))

            RatingCategory.M -> (MachinePartRange(x, range1, a, s)
                    to MachinePartRange(x, range2, a, s))

            RatingCategory.A -> (MachinePartRange(x, m, range1, s)
                    to MachinePartRange(x, m, range2, s))

            RatingCategory.S -> (MachinePartRange(x, m, a, range1)
                    to MachinePartRange(x, m, a, range2))
        }
    }
}

class Day19(val input: List<List<String>>) {

    // private val parsed: Pair<WorkflowSet, List<MachinePart>> get() { ... }

    // fun solvePart1(): Int { ... }

    // In part two, we stop caring about the individual parts altogether!
    fun solvePart2(): Long {
        val (workflows, _) = parsed
        return workflows.findAllApprovedPartRanges()
            .sumOf { it.totalCombinations }
    }
}

Reminds me of Day 5, to be honest, although the range splitting is a lot simpler this time around.

Wrap Up

I really enjoyed today’s puzzle. You ever have that experience where you’ve broken a problem down into bite-size pieces, worked each piece, then when the last piece clicks into place it’s a bit of a surprise to realize that you’re done? That was me with today’s puzzle. It happens that way sometimes, and I love it. After solving the puzzle I did a bit of reading on hypercubes and other words I don’t know the meaning of, but thinking about today’s problem in terms of ranges makes the most sense to me. This has been my favorite so far.

Advent of Code 2023 - Day 18

Mon, 18 Dec 2023 00:00:00 +0000

Day 18 - Lavaduct Lagoon

Find the problem description HERE.

The Input - Can You Dig It?

It turns out that, actually, you shouldn’t dig the entire thing, but we’ll get to why later. The interesting thing about this puzzle is that the shape described by the input can be represented as a polygon by tracking the vertices and edges. But before we get to that, let’s just formalize the input lines into objects.


import dev.ericburden.aoc2023.Utils.CardinalDirection

/**
 * This class represents an instruction from the input file.
 *
 * Each line in the input file can be parsed to an instruction to dig 1x1m
 * sections into a grid, in any cardinal direction.
 *
 * @property direction The direction in which to dig.
 * @property length The number of spaces to dig.
 * @property color The color of the trench walls.
 */
data class DigInstruction(
    val direction: CardinalDirection,
    val length: Long,
    val color: String
) {
    companion object {
        /**
         * Parse one line from the input file into a [DigInstruction]
         *
         * @param line A line from the input file.
         * @return The parsed [DigInstruction].
         */
        fun fromInputLine(line: String): DigInstruction {
            val (dirStr, lenStr, colStr) = line.split("\\s+".toRegex())
            val direction = when (dirStr) {
                "U" -> CardinalDirection.NORTH
                "R" -> CardinalDirection.EAST
                "D" -> CardinalDirection.SOUTH
                "L" -> CardinalDirection.WEST
                else -> throw Exception("Cannot parse $dirStr to a direction!")
            }
            val length = lenStr.toLongOrNull()
                ?: throw Exception("Cannot parse $lenStr to a number!")

            // Strip everything but the hex digits from color
            val color = colStr.trim('(', ')', '#')
            return DigInstruction(direction, length, color)
        }
    }
}

class Day18(input: List<String>) {

    // Parse each line in the input into an instruction, and prepare to
    // follow them.
    private val parsed =
        input.filter { it.isNotEmpty() }.map(DigInstruction::fromInputLine)

}

There’s more to come, but we’ll do that in Part One.

Part One - Going, Going, Poly-GON

Yes, I know you wanted to simulate digging out that trench, flood filling the interior, then counting the dug out grid spaces. So did I! Here’s the thing: today I learned about the Surveyor’s Formula or the Shoestring Method, by which one can calculate the area of any irregular polygon. How cool is that? Here’s how that works.


import dev.ericburden.aoc2023.Utils.CardinalDirection
import kotlin.math.abs

data class DigInstruction(
    val direction: CardinalDirection,
    val length: Long,
    val color: String
) {
    // companion object { ... }
}

// We're going to use polygons today! Our polygon will consist of vertices
// and edges.
data class Vertex(val x: Long, val y: Long)
data class Edge(val v1: Vertex, val v2: Vertex, val len: Long)

/**
 * Convert a list of [DigInstruction]s to a [Polygon]
 *
 * This function extends the functionality of a [List<DigInstruction>] by adding
 * the function `toPolygon`, which allows for trivially converting a list of
 * dig instructions into vertices and edges and, thus, a polygon.
 *
 * @return The resulting [Polygon].
 */
fun List<DigInstruction>.toPolygon(): Polygon {
    // We start at the origin. This is arbitrary, but it's as good a place to
    // start as any.
    val vertices = mutableListOf(Vertex(0, 0))
    val edges = mutableListOf<Edge>()

    // For each instruction, we calculate the location of the next vertex from
    // the dig instruction. We can then use that location, along with the last
    // vertex, to calculate the edge with the last vertex and the newly added
    // vertex.
    for (instruction in this) {
        val (lastRow, lastCol) = vertices.last()
        val vertex = when (instruction.direction) {
            CardinalDirection.NORTH -> Vertex(
                lastRow - instruction.length,
                lastCol
            )

            CardinalDirection.EAST -> Vertex(
                lastRow,
                lastCol + instruction.length
            )

            CardinalDirection.SOUTH -> Vertex(
                lastRow + instruction.length,
                lastCol
            )

            CardinalDirection.WEST -> Vertex(
                lastRow,
                lastCol - instruction.length
            )
        }
        vertices.add(vertex)
        edges.add(Edge(vertices.last(), vertex, instruction.length))
    }
    return Polygon(vertices, edges)
}

fun <T> Sequence<T>.append(value: T): Sequence<T> = sequence {
    yieldAll(this@append)
    yield(value)
}

/**
 * This class represents a 2-dimensional polygon.
 *
 * @property vertices A list of vertices in the polygon.
 * @property edges A list of edges in the polygon.
 */
data class Polygon(val vertices: List<Vertex>, val edges: List<Edge>) {

    // Calculate and return the area of the polygon using the "shoestring"
    // or "surveyor's" method. A nice explanation of this can be found
    // [here](https://www.themathdoctors.org/polygon-coordinates-and-areas/)
    val area: Long get() {
        var lastVertex = vertices.first()
        var leftShoelace = 0L
        var rightShoelace = 0L
        for (nextVertex in vertices.drop(1)) {
            val (x1, y1) = lastVertex
            val (x2, y2) = nextVertex
            leftShoelace += x1 * y2
            rightShoelace += x2 * y1
            lastVertex = nextVertex
        }
        return abs(leftShoelace - rightShoelace) / 2
    }

    // Calculate and return the perimeter of the polygon. It's the sum of
    // all the edge lengths.
    val perimeter: Long get() = edges.sumOf { (_, _, len) -> len }
}

/**
 * This class represents the dig site.
 *
 * Mostly just serves as a wrapper around a [Polygon] to account for the
 * thickness of the trench dug around the outside of the eventual lava lagoon.
 * We need to account for this because the trench counts as spaces where the
 * lava can go.
 *
 * @property polygon The inner polygon formed by digging around the lagoon area.
 */
data class DigSite(val polygon: Polygon) {

    // So, how does the thick line of the trench contribute to overall area
    // available for lava. Consider that the infinitesimal point in space
    // that defines the origin is the point in the exact center of the
    // first 1x1 cube dug. The area, as calculated, is thus bound by an
    // infinitely thin line running through the center of the trench cubes.
    // This means that, for your average side section of the trench, have that
    // trench cube is in the area and half of it is outside and needs to be
    // added back in. The exception here are corner trench cubes. For the four
    // corners, 3/4 of that cube is outside the bounded region. This means an
    // extra 1/4 of a trench cube for each, and for four corners... It's an
    // estra `+ 1`. The _inner_ corners (those bends and twists in the walls)
    // don't matter because for every cube 3/4 inside the bounded area, there's
    // a corresponding cube with only 1/4 inside the bounded area.
    val volume: Long get() = polygon.area + (polygon.perimeter / 2) + 1
}

// Conveniently convert a list of dig instructions to a [DigSite]
fun List<DigInstruction>.toDigSite() = DigSite(this.toPolygon())

class Day18(input: List<String>) {

    // private val parsed = ...

    // In part one, we don't actually _follow_ the instructions so much as use
    // math as a shortcut!
    fun solvePart1(): Long = parsed.toDigSite().volume

}

To be fair, flood-filling would definitely have worked for part one. Part two, though…

Part Two - Dig It Real Good

Surprise! We misinterpreted the input again! This time, though, I think we could be forgiven. I mean, who encodes directions in color codes? Elves, I guess. After decoding these new instructions, the trench will be huge. And now you know why we couldn’t do the flood fill.


import dev.ericburden.aoc2023.Utils.CardinalDirection
import kotlin.math.abs

data class DigInstruction(
    val direction: CardinalDirection,
    val length: Long,
    val color: String
) {
    // companion object { ... }

    /**
     * Recode a [DigInstruction] based on the part 2 parsing strategy.
     *
     * Turns out those colors _were_ useful after all, just not in any way I
     * would have guessed while solving part one. The color codes actually
     * hold the digging information, and we need to use that instead.
     *
     * @return A re-coded [DigInstruction].
     */
    fun recode(): DigInstruction {
        val firstFive = color.take(5)
        val lastChar = color.last()
        val length = firstFive.toLong(16) // This is super handy
        val direction = when (lastChar) {
            '0' -> CardinalDirection.EAST
            '1' -> CardinalDirection.SOUTH
            '2' -> CardinalDirection.WEST
            '3' -> CardinalDirection.NORTH
            else -> throw Exception("Could not parse $lastChar to a direction!")
        }
        return DigInstruction(direction, length, "#ffffff")
    }
}

// We're going to use polygons today! Our polygon will consist of vertices
// and edges.
data class Vertex(val x: Long, val y: Long)
data class Edge(val v1: Vertex, val v2: Vertex, val len: Long)

// fun List<DigInstruction>.toPolygon(): Polygon { ... }

// fun <T> Sequence<T>.append(value: T): Sequence<T> = ...

data class Polygon(val vertices: List<Vertex>, val edges: List<Edge>) {

    // val area: Long get() { ... }

    // val perimeter: Long get() = ...
}

data class DigSite(val polygon: Polygon) {

    // val volume: Long get() = ...
}

// Conveniently convert a list of dig instructions to a [DigSite]
fun List<DigInstruction>.toDigSite() = DigSite(this.toPolygon())

class Day18(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Long = ...

    // In part two, it's a good thing we used math, because we would _never_
    // actually finish digging that pit and counting the inner area.
    fun solvePart2(): Long =parsed.map { it.recode() }.toDigSite().volume

}

And that’s the power of geometry!

Wrap Up

This is one my favorite kinds of puzzles: the kind that help me answer questions I didn’t know I had! In this one, I realized after searching up the Shoestring Method and reading about it that what we’re really doing is dividing the polygon up into triangles, calculating their areas, then returning the total area (more or less). Back in my day, you’d see the technique of dividing surfaces up into triangles all over video games (remember the original Playstation? Anyone?). I’d bet a shiny nickel that at least parts of this approach were involved in that. At any rate, that’s how I’m going to remember this approach for next time.

Advent of Code 2023 - Day 17

Sun, 17 Dec 2023 00:00:00 +0000

Day 17 - Clumsy Crucible

Find the problem description HERE.

The Input - These City Streets

Today’s input parsing is… pretty much all done by the pre-processor. I did write a new function to handle grids of digits, though, so that’s cool. Check this out!

fun resourceAsGridOfDigits(fileName: String): List<List<Int>> =
    resourceAsLines(fileName).map { it.map { char -> char.digitToInt() } }

Now I can use this function to read the file (much like the resourceAsGridOfChar from the last few days). With that integer grid in hand, I just pop it into a data class so I can attach new methods to it.

/**
 * This class represents the grid of city blocks (and their heat loss amounts)
 *
 * @property grid The grid of heat loss amounts for each city block.
 */
data class CityBlocks(val grid: List<List<Int>>) {
    // Convenience!
    val rows: Int get() = grid.size
    val cols: Int get() = grid.first().size

    // Index a [LaserGrid] with an [Index2D].
    operator fun get(idx: Index2D): Int = grid[idx.row][idx.col]

    /**
     * Check if a crucible is still on the grid
     *
     * @param crucible The crucible to check.
     * @return Is the laser still on the grid?
     */
    private fun isInBounds(crucible: Crucible): Boolean {
        val (row, col) = crucible.position
        return row in 0..<rows && col in 0..<cols
    }
}


class Day17(input: List<List<Int>>) {

    // Put the grid in the data class and get ready to rock.
    private val parsed = CityBlocks(input)
    
}

I feel like I need a Grid superclass that I can attach all these convenience functions to so I don’t need to re-type them every day. The muscle memory is nice and all, but programming means making my own life easier!

Part One - Roll That Beautiful Lava Bucket

Now that we have lava, there’s no choice but to roll it through (potentially) crowded city streets. But, on the plus side, we have lava! Also, the crucibles are hard to steer, apparently. Nothing can go wrong!

// For more on these re-used classes and functions, check out earlier
// day blog posts or just look at the code on GitHub.
import dev.ericburden.aoc2023.Utils.Index2D
import dev.ericburden.aoc2023.Utils.Offset2D
import dev.ericburden.aoc2023.Utils.plus
import java.util.PriorityQueue

/**
 * This enum represents the four cardinal directions
 *
 * The four cardinal directions are north, south, east, and west. This
 * enum also provides methods for turning from one cardinal direction
 * to another.
 */
enum class CardinalDirection {
    NORTH, SOUTH, EAST, WEST;

    // Turn this direction to the left
    fun turnLeft(): CardinalDirection = when (this) {
        NORTH -> WEST
        EAST -> NORTH
        SOUTH -> EAST
        WEST -> SOUTH
    }

    // Turn this direction to the right
    fun turnRight(): CardinalDirection = when (this) {
        NORTH -> EAST
        EAST -> SOUTH
        SOUTH -> WEST
        WEST -> NORTH
    }
}

/**
 * This class represents a big ole crucible, rolling through the streets
 *
 * @property position The location of the crucible on the 2D grid.
 * @property direction The direction the crucible is currently heading.
 * @property run The number of blocks this crucible has moved in a straight line.
 * @property kind The kind of crucible we have (REGULAR or ULTRA).
 */
data class Crucible(
    val position: Index2D,
    val direction: CardinalDirection,
    val run: Int,
) {
    /**
     * Move the crucible forward.
     *
     * @return The crucible that would result from moving this crucible forward
     * one step in the direction it is currently going.
     */
    private fun advance(): Crucible {
        // Update the position with offsets.
        val position = position + when (direction) {
            CardinalDirection.NORTH -> Offset2D(-1, 0)
            CardinalDirection.EAST -> Offset2D(0, 1)
            CardinalDirection.SOUTH -> Offset2D(1, 0)
            CardinalDirection.WEST -> Offset2D(0, -1)
        }

        // Increase the run distance
        val run = run + 1

        // Everything else stays the same
        return Crucible(position, direction, run)
    }

    /**
     * Turn the crucible to the left without moving forward
     *
     * @return The crucible that results from turning this crucible to the left.
     */
    private fun turnLeft(): Crucible {
        // Change heading
        val direction = direction.turnLeft()

        // Reset the run to zero when we turn
        return Crucible(position, direction, 0)
    }

    /**
     * Turn the crucible to the right without moving forward
     *
     * @return The crucible that results from turning this crucible to the right.
     */
    private fun turnRight(): Crucible {
        // Change heading
        val direction = direction.turnRight()

        // Reset the run to zero when we turn
        return Crucible(position, direction, 0)
    }

    /**
     * Identify which states are possible for this crucible
     *
     * A crucible can always move left or right, but it can only move forward
     * when the run length is less than three.
     *
     * @return A list of all the possible next states for this crucible based
     * on its current state.
     */
    fun nextStates() = if (run < 3) {
        listOf(
            advance(),
            turnLeft().advance(),
            turnRight().advance()
        )
    } else {
        listOf(
            turnLeft().advance(),
            turnRight().advance()
        )
    }
}

data class CityBlocks(val grid: List<List<Int>>) {
    // val rows: Int get() = ...
    // val cols: Int get() = ...

    // operator fun get(idx: Index2D): Int = ...

    // private fun isInBounds(crucible: Crucible): Boolean { ... }
    
    
    /**
     * Find the shortest path from a starting [Crucible] state to the end index
     *
     * This is an implementation of Dijkstra's algorithm for finding the
     * shortest path. I _considered_ going full A* here, but this runs in
     * a sufficiently reasonable amount of time, so I'll leave it as-is.
     *
     * @param start The starting state of our crucible.
     * @param end The index we're pathfinding to.
     */
    fun shortestPath(start: Crucible, end: Index2D): Int {
        // Minimum priority queue of <heat loss>, <crucible> pairs, ordered by
        // minimum heat loss.
        val queue =
            PriorityQueue<Pair<Int, Crucible>> { o1, o2 -> o1.first - o2.first }
        queue.add(0 to start)

        // Mapping of minimum heat attained per crucible state. This can't just
        // be position, because the path from a particular location will vary
        // depending on the direction and run length as well.
        val minHeatLosses = HashMap<Crucible, Int>()
        minHeatLosses[start] = 0

        // Find that path!
        while (queue.isNotEmpty()) {
            // Get the state with the minimum heat loss so far from the queue
            val (heatLost, crucible) = queue.remove()

            // If we've reached the end, we win!
            if (crucible.position == end) return heatLost

            // Otherwise, identify all the possible next states for the
            // current crucible.
            val nextStates = crucible.nextStates().filter { isInBounds(it) }

            // For each possible future state...
            for (state in nextStates) {
                // Check to see if the heat loss for reaching this new state
                // can be less than any previous amount of heat lost reaching
                // this state.
                val newHeatLoss = heatLost + this[state.position]
                val previousMinHeatLoss = minHeatLosses[state] ?: Int.MAX_VALUE

                // If so, we've found a new shortest path to this state. Add
                // it to the queue!
                if (newHeatLoss < previousMinHeatLoss) {
                    minHeatLosses[state] = newHeatLoss
                    queue.add(newHeatLoss to state)
                }

            }
        }

        // When disaster strikes! If we search through all possible paths and
        // don't reach the end _ever_ we get this exception.
        throw Exception("Could not find a path to $end from $start!")
    }   
}


class Day17(input: List<List<Int>>) {

    // private val parsed = ...

    // In part one, we use regular, everyday giant rolling crucibles to move
    // lava around city streets. Totally safe.
    fun solvePart1(): Int {
        val topLeftCrucible = Crucible(Index2D(0, 0), CardinalDirection.EAST, 0)
        val bottomRightIdx = Index2D(parsed.rows - 1, parsed.cols - 1)
        return parsed.shortestPath(topLeftCrucible, bottomRightIdx)
    }
    
}

It just wouldn’t be Advent of Code without Dijkstra’s algorithm. I was wondering when we’d see the old guy, and here he is! There’s a bit of a twist with needing to turn the crucible sometimes, but nothing our nextStates logic can’t handle.

Part Two - Go Ultra, or Go Home

Turns out, what we really need to get all the lava where it needs to go are larger, more difficult to steer crucibles. It’s time to go ultra! The main differences here are that the rules for determining possible next states has changed a bit. Also, we can’t always stop. Yeah… Well, the one thing that doesn’t change, actually, is our pathfinding algorithm. So, that’s nice.

// For more on these re-used classes and functions, check out earlier
// day blog posts or just look at the code on GitHub.
import dev.ericburden.aoc2023.Utils.Index2D
import dev.ericburden.aoc2023.Utils.Offset2D
import dev.ericburden.aoc2023.Utils.plus
import java.util.PriorityQueue


// enum class CardinalDirection { ... }

// In part two, we have ULTRA crucibles, which behave a little differently
enum class CrucibleKind { REGULAR, ULTRA; }

/**
 * This class represents a big ole crucible, rolling through the streets
 *
 * @property position The location of the crucible on the 2D grid.
 * @property direction The direction the crucible is currently heading.
 * @property run The number of blocks this crucible has moved in a straight line.
 * @property kind The kind of crucible we have (REGULAR or ULTRA).
 */
data class Crucible(
    val position: Index2D,
    val direction: CardinalDirection,
    val run: Int,
    val kind: CrucibleKind = CrucibleKind.REGULAR
) {
    /**
     * Move the crucible forward.
     *
     * @return The crucible that would result from moving this crucible forward
     * one step in the direction it is currently going.
     */
    private fun advance(): Crucible {
        // Update the position with offsets.
        val position = position + when (direction) {
            CardinalDirection.NORTH -> Offset2D(-1, 0)
            CardinalDirection.EAST -> Offset2D(0, 1)
            CardinalDirection.SOUTH -> Offset2D(1, 0)
            CardinalDirection.WEST -> Offset2D(0, -1)
        }

        // Increase the run distance
        val run = run + 1

        // Everything else stays the same
        return Crucible(position, direction, run, kind)
    }

    /**
     * Turn the crucible to the left without moving forward
     *
     * @return The crucible that results from turning this crucible to the left.
     */
    private fun turnLeft(): Crucible {
        // Change heading
        val direction = direction.turnLeft()

        // Reset the run to zero when we turn
        return Crucible(position, direction, 0, kind)
    }

    /**
     * Turn the crucible to the right without moving forward
     *
     * @return The crucible that results from turning this crucible to the right.
     */
    private fun turnRight(): Crucible {
        // Change heading
        val direction = direction.turnRight()

        // Reset the run to zero when we turn
        return Crucible(position, direction, 0, kind)
    }

    /**
     * Identify which states are possible for this crucible
     *
     * @return A list of all the possible next states for this crucible based
     * on its current state.
     */
    fun nextStates() = when (kind) {
        // A regular crucible (part one) can always move left or right, but
        // it can only move forward when the run length is less than three.
        CrucibleKind.REGULAR -> if (run < 3) {
            listOf(
                advance(),
                turnLeft().advance(),
                turnRight().advance()
            )
        } else {
            listOf(
                turnLeft().advance(),
                turnRight().advance()
            )
        }

        // An _ultra_ crucible (part two) can _only_ move forward if its run
        // length is less than four (or it's on the first space). With run
        // lengths of 4-9 (inclusive) it can move forward, left, or right just
        // like a regular crucible. At a run length of 10, it must turn.
        CrucibleKind.ULTRA -> if (run < 4 && (position.row != 0 || position.col != 0)) {
            listOf(advance())
        } else if (run < 10) {
            listOf(
                advance(),
                turnLeft().advance(),
                turnRight().advance()
            )
        } else {
            listOf(
                turnLeft().advance(),
                turnRight().advance()
            )
        }
    }

    /**
     * Indicates whether this crucible can stop
     *
     * A regular crucible can stop any time, but an _ultra_ crucible can only
     * stop after moving at least four blocks in a straight line.
     *
     * @return A flag indicating whether this crucible can stop moving.
     */
    fun canStop() = when (kind) {
        CrucibleKind.REGULAR -> true
        CrucibleKind.ULTRA -> run >= 4
    }
}

data class CityBlocks(val grid: List<List<Int>>) {
    // val rows: Int get() = ...
    // val cols: Int get() = ...

    // operator fun get(idx: Index2D): Int = ...

    // private fun isInBounds(crucible: Crucible): Boolean { ... }
    
    fun shortestPath(start: Crucible, end: Index2D): Int {
        // Minimum priority queue of <heat loss>, <crucible> pairs, ordered by
        // minimum heat loss.
        val queue =
            PriorityQueue<Pair<Int, Crucible>> { o1, o2 -> o1.first - o2.first }
        queue.add(0 to start)

        // Mapping of minimum heat attained per crucible state. This can't just
        // be position, because the path from a particular location will vary
        // depending on the direction and run length as well.
        val minHeatLosses = HashMap<Crucible, Int>()
        minHeatLosses[start] = 0

        // Find that path!
        while (queue.isNotEmpty()) {
            // Get the state with the minimum heat loss so far from the queue
            val (heatLost, crucible) = queue.remove()

            // ****************************************************************

            // Turns out, I did need to change the pathfinding algorithm a
            // _smidge_. Need to check to see if we can stop before declaring
            // we've found our way through.
            if (crucible.position == end && crucible.canStop()) return heatLost

            // ****************************************************************

            // Otherwise, identify all the possible next states for the
            // current crucible.
            val nextStates = crucible.nextStates().filter { isInBounds(it) }

            // For each possible future state...
            for (state in nextStates) {
                // Check to see if the heat loss for reaching this new state
                // can be less than any previous amount of heat lost reaching
                // this state.
                val newHeatLoss = heatLost + this[state.position]
                val previousMinHeatLoss = minHeatLosses[state] ?: Int.MAX_VALUE

                // If so, we've found a new shortest path to this state. Add
                // it to the queue!
                if (newHeatLoss < previousMinHeatLoss) {
                    minHeatLosses[state] = newHeatLoss
                    queue.add(newHeatLoss to state)
                }

            }
        }

        // When disaster strikes! If we search through all possible paths and
        // don't reach the end _ever_ we get this exception.
        throw Exception("Could not find a path to $end from $start!")
    }
}


class Day17(input: List<List<Int>>) {

    // private val parsed = ...

    // fun solvePart1(): Int { ... }

    // In part two, we use _ultra_ crucibles, which are way more ultra than
    // regular crucibles in every conceivable way.
    fun solvePart2(): Int {
        val topLeftCrucible = Crucible(
            Index2D(0, 0), CardinalDirection.EAST, 0, CrucibleKind.ULTRA
        )
        val bottomRightIdx = Index2D(parsed.rows - 1, parsed.cols - 1)
        return parsed.shortestPath(topLeftCrucible, bottomRightIdx)
    }
    
}

We’ve got a bit of a “strategy pattern” thing going with our Crucible now, where the behaviour changes based on what kind of Crucible it is. Again, I started to reach for an abstract class/subclass setup, but I can’t figure out a way to get those shared functions (in this case, advance, turnLeft, and turnRight) to live in the abstract class and still return instances of the subclass that used the method. I could have those methods mutate the object directly, but that seems like it shouldn’t be required. Probably a skill issue.

Wrap Up

Hello Dijkstra, my old friend! Today’s puzzle was in classic Advent of Code style, pathfinding with rules for which next states are possible. If we see another of these (and we’re likely to), I think I’m going to try abstracting out some of the basic operations I use on grids all the time, like indexing in two dimensions and getting the number of rows and columns.

Advent of Code 2023 - Day 16

Sat, 16 Dec 2023 00:00:00 +0000

Day 16 - The Floor Will Be Lava

Find the problem description HERE.

The Input - Rudolph The Red-Nosed Laser Engineer

Another day, another grid of characters here in Advent of Code. Thankfully, we know how to deal with these. Today, I decided to try a more object-oriented approach with the grid and make each cell a concrete subclass of an abstract base class. OO is not my lingua franca, but I think it came together well.


/**
 * This class serves as the superclass for all grid cells
 *
 * Each cell in the grid is represented by a subclass of this
 * [AbstractLaserGridCell]. All cells start out without energy but can be
 * energized by having the laser pass through the cell.
 *
 * @property energized Indicates whether a laser has passed through this cell.
 */
abstract class AbstractLaserGridCell(var energized: Boolean = false) {
    companion object {
        /**
         * Parse a concrete instance of an [AbstractLaserGridCell] from a character
         *
         * Each character in the input corresponds to a particular subclass of
         * [AbstractLaserGridCell].
         *
         * @param char A character from the input file.
         * @return The corresponding concrete grid cell.
         */
        fun fromChar(char: Char): AbstractLaserGridCell {
            return when (char) {
                '.' -> EmptyGridCell(false)
                '|' -> VerticalSplitterGridCell(false)
                '-' -> HorizontalSplitterGridCell(false)
                '/' -> RightLeaningMirrorGridCell(false)
                '\\' -> LeftLeaningMirrorGridCell(false)
                else -> throw Exception("$char is not a valid kind of grid cell!")
            }
        }
    }

    // For printing! By which I mean debugging!
    abstract override fun toString(): String
}


// This subclass represents an empty grid cell, '.'
class EmptyGridCell(energized: Boolean) : AbstractLaserGridCell(energized) {

    override fun toString(): String = if (energized) "#" else "."

}

// This subclass represents a vertical splitter, '|'
class VerticalSplitterGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {

    override fun toString(): String = if (energized) "#" else "|"

}

// This subclass represents a horizontal splitter, '-'
class HorizontalSplitterGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {


    override fun toString(): String = if (energized) "#" else "-"

}

// This subclass represents a right-leaning mirror, '/'
class RightLeaningMirrorGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {

    override fun toString(): String = if (energized) "#" else "/"

}

// This subclass represents a left-leaning mirror, '\'
class LeftLeaningMirrorGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {

    override fun toString(): String = if (energized) "#" else "\\"

}

// Convenience!
fun MutableList<MutableList<AbstractLaserGridCell>>.wrap(): LaserGrid =
    LaserGrid(this)

/**
 * This class represents a grid of cells that we can shoot lasers through
 *
 * @property grid The grid of cells composing this [LaserGrid].
 */
data class LaserGrid(val grid: MutableList<MutableList<AbstractLaserGridCell>>) {
    companion object {
        /**
         * Parse a [LaserGrid] from the input file
         *
         * @param input A grid of characters from the input.
         * @return A parsed [LaserGrid].
         */
        fun fromInput(input: List<List<Char>>): LaserGrid = input.map { row ->
            row.map(AbstractLaserGridCell::fromChar).toMutableList()
        }.toMutableList().wrap()
    }

    private val rows: Int get() = grid.size
    private val cols: Int get() = grid.first().size

    // Still debugging!
    override fun toString(): String =
        grid.joinToString("\n") { row -> row.joinToString("") { cell -> cell.toString() } }

}


class Day16(input: List<List<Char>>) {

    // Turn those characters into a [LaserGrid]!
    private val parsed = LaserGrid.fromInput(input)
    
}

I realize that letting the grid inside LaserGrid be mutable can cause problems for me later on, but I account for that. Honest!

Part One - Pew, Pew

Oh boy, now we get to see what all that focusing from the past two days has done! And what it has done is make lasers!!!! Good thing we’re dealing with elves instead of stormtroopers or we’d never be able to hit these mirrors. Our goal in part one today is to unleash a mighty beam of unstoppable fury (lasers are cool) into a grid containing mirrors and splitters and see which cells get exposed to the laser.


abstract class AbstractLaserGridCell(var energized: Boolean = false) {
    // companion object { ... }
    

    /**
     * Energize this cell when it's shot with a laser
     */
    fun energize() {
        this.energized = true
    }

    // Deflects a laser to the next set of cells
    abstract fun deflect(laser: Laser): List<Laser>

    // We need to be able to copy these so we can avoid issues with sneaky
    // mutations.
    abstract fun copy(): AbstractLaserGridCell
}


// This subclass represents an empty grid cell, '.'
class EmptyGridCell(energized: Boolean) : AbstractLaserGridCell(energized) {
    // Lasers that enter this cell are just forwarded to the next cell.
    override fun deflect(laser: Laser): List<Laser> =
        listOf(laser.advance())

    override fun copy() = EmptyGridCell(energized)

}

// This subclass represents a vertical splitter, '|'
class VerticalSplitterGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {
    // Lasers in this cell moving north or south just keep going. Lasers
    // moving east or west are split.
    override fun deflect(laser: Laser): List<Laser> = when (laser.heading) {
        LaserHeading.NORTH -> listOf(laser.advance())
        LaserHeading.SOUTH -> listOf(laser.advance())
        else -> listOf(laser.turnLeftAndAdvance(), laser.turnRightAndAdvance())
    }

    override fun copy() = VerticalSplitterGridCell(energized)

}

// This subclass represents a horizontal splitter, '-'
class HorizontalSplitterGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {
    // Lasers in this cell heading east and west just keep going. Lasers
    // moving north or south are split.
    override fun deflect(laser: Laser): List<Laser> = when (laser.heading) {
        LaserHeading.EAST -> listOf(laser.advance())
        LaserHeading.WEST -> listOf(laser.advance())
        else -> listOf(laser.turnLeftAndAdvance(), laser.turnRightAndAdvance())
    }

    override fun copy() = HorizontalSplitterGridCell(energized)

}

// This subclass represents a right-leaning mirror, '/'
class RightLeaningMirrorGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {
    // Lasers in this cell heading north or south are turned to the right.
    // Lasers going east or west are turned to the left.
    override fun deflect(laser: Laser): List<Laser> = when (laser.heading) {
        LaserHeading.NORTH -> listOf(laser.turnRightAndAdvance())
        LaserHeading.EAST -> listOf(laser.turnLeftAndAdvance())
        LaserHeading.SOUTH -> listOf(laser.turnRightAndAdvance())
        LaserHeading.WEST -> listOf(laser.turnLeftAndAdvance())
    }

    override fun copy() = RightLeaningMirrorGridCell(energized)

}

// This subclass represents a left-leaning mirror, '\'
class LeftLeaningMirrorGridCell(energized: Boolean) :
    AbstractLaserGridCell(energized) {
    // Lasers in this cell heading north or south are turned to the left.
    // Lasers going east or west are turned to the right.
    override fun deflect(laser: Laser): List<Laser> = when (laser.heading) {
        LaserHeading.NORTH -> listOf(laser.turnLeftAndAdvance())
        LaserHeading.EAST -> listOf(laser.turnRightAndAdvance())
        LaserHeading.SOUTH -> listOf(laser.turnLeftAndAdvance())
        LaserHeading.WEST -> listOf(laser.turnRightAndAdvance())
    }

    override fun copy() = LeftLeaningMirrorGridCell(energized)

}

// This class represents an index in a 2-dimensional grid
data class Index2D(val row: Int, val col: Int)

// This class represents an offset from a grid position. Used to shift
// a position by adding this offset to a position.
data class Offset2D(val rows: Int, val cols: Int)

// Implement adding [Offset2D] to an [Index2D]
operator fun Index2D.plus(offset: Offset2D): Index2D =
    Index2D(row + offset.rows, col + offset.cols)

// Convenience!
fun MutableList<MutableList<AbstractLaserGridCell>>.wrap(): LaserGrid =
    LaserGrid(this)

/**
 * This enum class represents all four directions a laser could travel in
 *
 * A laser can travel north, south, east, or west.
 */
enum class LaserHeading {
    NORTH, EAST, SOUTH, WEST;

    // Turn this direction to the left
    fun turnLeft(): LaserHeading = when (this) {
        NORTH -> WEST
        EAST -> NORTH
        SOUTH -> EAST
        WEST -> SOUTH
    }

    // Turn this direction to the right
    fun turnRight(): LaserHeading = when (this) {
        NORTH -> EAST
        EAST -> SOUTH
        SOUTH -> WEST
        WEST -> NORTH
    }
}

/**
 * This class represents a _LAZER_
 *
 * I really thought about using another abstract/subclass setup for lasers,
 * and even started down that path, but it actually made my code _more_
 * complicated (to me, at least).
 *
 * @property position The position of the laser in a grid.
 * @property heading The direction this laser is moving.
 */
data class Laser(
    val position: Index2D = Index2D(0, 0),
    val heading: LaserHeading = LaserHeading.EAST
) {
    /**
     * Advance the laser forward by one space
     *
     * @return A Laser in the next position.
     */
    fun advance(): Laser {
        val newPosition = position + when (heading) {
            LaserHeading.NORTH -> Offset2D(-1, 0)
            LaserHeading.EAST -> Offset2D(0, 1)
            LaserHeading.SOUTH -> Offset2D(1, 0)
            LaserHeading.WEST -> Offset2D(0, -1)
        }
        return Laser(newPosition, heading)
    }

    // Turn the laser right and move it forward one space
    fun turnRightAndAdvance() = Laser(position, heading.turnRight()).advance()

    // Turn the laser left and move it forward one space
    fun turnLeftAndAdvance() = Laser(position, heading.turnLeft()).advance()
}

data class LaserGrid(val grid: MutableList<MutableList<AbstractLaserGridCell>>) {
    // companion object { ... }

    // Index a [LaserGrid] with an [Index2D].
    operator fun get(idx: Index2D): AbstractLaserGridCell =
        grid[idx.row][idx.col]

    // Set values in a [LaserGrid] with an [Index2D].
    operator fun set(position: Index2D, value: AbstractLaserGridCell) {
        this.grid[position.row][position.col] = value
    }

    /**
     * Check if a laser is still on the grid
     *
     * @param laser The laser to check.
     * @return Is the laser still on the grid?
     */
    private fun isInBounds(laser: Laser): Boolean {
        val (row, col) = laser.position
        return row in 0..<rows && col in 0..<cols
    }

    /**
     * Shoot tha lazerz!!!
     *
     * Given a laser at a particular position and heading, allow that laser to
     * move around the grid energizing cells while being split and turned. Once
     * the full path of the laser has been determined, return a copy of this
     * [LaserGrid] with the cells the laser passed through energized.
     *
     * @param laser The starting [Laser]
     * @return A copy of this [LaserGrid], with cells exposed to laser energized.
     */
    fun applyLaser(laser: Laser): LaserGrid {
        // Going to trace the path of the laser with a depth-first search,
        // so we're going to need a stack.
        val stack = mutableListOf(laser)

        // Just in case there are loops in the path of the laser, this will
        // keep us from tracing those loops over and over again.
        val seen = HashSet<Laser>()

        // Work on and return a deep copy of the current grid, to avoid
        // issues with persistent mutations.
        val laserGrid =
            this.grid.map { row -> row.map { it.copy() }.toMutableList() }
                .toMutableList().wrap()

        // Now, so long as there are lasers still moving around, we take the
        // next laser to move off the stack and move it forward, turning and
        // splitting as necessary.
        while (stack.isNotEmpty()) {
            val currentLaser = stack.removeLast()
            seen.add(currentLaser) // Won't do _that_ again!

            // Get and energize the cell currently occupied by the laser
            val currentCell = laserGrid[currentLaser.position]
            currentCell.energize()

            // Get the next laser(s) from moving this one. If we're on a
            // splitter, it might be _two_ new lasers.
            val nextLasers = currentCell.deflect(currentLaser)
                .filter { laserGrid.isInBounds(it) }

            // Add each new laser we haven't seen at this position and
            // direction to the stack to check next.
            for (nextLaser in nextLasers) {
                if (seen.contains(nextLaser)) continue
                stack.add(nextLaser)
            }
        }

        // Remember, this is a copy, not the original.
        return laserGrid
    }

    // Calculate the total number of energized cells in this [LaserGrid].
    fun totalEnergy(): Int = grid.sumOf { row -> row.count { it.energized } }

}


class Day16(input: List<List<Char>>) {

    // private val parsed = ...

    // In part one, we shoot tha lazer, and see where it goes.
    fun solvePart1() = parsed.applyLaser(Laser()).totalEnergy()
    
}

I feel like going more (but not full) OO ended up making the code a bit more verbose than it otherwise needed to be. There are still a number of moving parts here (despite the fact that the parts aren’t actually moving) to account for, so we end up with a lot of code. Ah well, it’s fine, it’s Saturday after all!

Part Two - The Only Thing Better Than One Laser…

… is all the lasers! In part two, we need to unleash a rain of molten light down upon this poor unsuspecting grid and find the maximum number of cells that can be affected by a beam of pure delight. Yes, I like lasers.


abstract class AbstractLaserGridCell(var energized: Boolean = false) {
    // companion object { ... }
    
    // fun energize() { ... }

    // abstract fun deflect(laser: Laser): List<Laser>

    // abstract fun copy(): AbstractLaserGridCell
}


// class EmptyGridCell(energized: Boolean) : AbstractLaserGridCell(energized) { ... }

// class VerticalSplitterGridCell(energized: Boolean) :
//     AbstractLaserGridCell(energized) { ... }

// class HorizontalSplitterGridCell(energized: Boolean) :
//     AbstractLaserGridCell(energized) { ... }

// class RightLeaningMirrorGridCell(energized: Boolean) :
//     AbstractLaserGridCell(energized) { ... }

// class LeftLeaningMirrorGridCell(energized: Boolean) :
//     AbstractLaserGridCell(energized) { ... }

// data class Index2D(val row: Int, val col: Int)

// data class Offset2D(val rows: Int, val cols: Int)

// operator fun Index2D.plus(offset: Offset2D): Index2D = ...

// fun MutableList<MutableList<AbstractLaserGridCell>>.wrap() = ...

// enum class LaserHeading { NORTH, EAST, SOUTH, WEST; ...}

// data class Laser(val position: Index2D, val heading: LaserHeading) { ... }

data class LaserGrid(val grid: MutableList<MutableList<AbstractLaserGridCell>>) {
    // companion object { ... }

    // operator fun get(idx: Index2D) = ...

    // operator fun set(position: Index2D, value: AbstractLaserGridCell) { ... }

    // private fun isInBounds(laser: Laser): Boolean { ... }

    /// fun applyLaser(laser: Laser): LaserGrid { ... }

    /// fun totalEnergy(): Int = ...

    /**
     * Determine _all_ the lasers we can pew, pew!
     *
     * Populate and return a list of all lasers that can be generated by walking
     * around the edge of the grid and shooting a laser away from the edge. As
     * described in the puzzle.
     */
    fun allPossibleLasers(): List<Laser> {
        val lasers = mutableListOf<Laser>()

        // All the left and right edges
        for (row in grid.indices) {
            lasers.add(Laser(Index2D(row, 0), LaserHeading.EAST))
            lasers.add(Laser(Index2D(row, cols - 1), LaserHeading.WEST))
        }

        // All the top and bottom edges
        for (col in grid.first().indices) {
            lasers.add(Laser(Index2D(0, col), LaserHeading.SOUTH))
            lasers.add(Laser(Index2D(rows - 1, col), LaserHeading.NORTH))
        }

        return lasers
    }

}


class Day16(input: List<List<Char>>) {

    // private val parsed = ...

    // fun solvePart1() = ...

    // In part two, I start to wonder whether sometimes brute force really
    // _is_ the intended answer. We check all possible starting positions
    // and directions for lasers and return the maximum grid energy found.
    fun solvePart2() =
        parsed.allPossibleLasers().maxOf { parsed.applyLaser(it).totalEnergy() }
    
}

Let’s be honest, brute force really is the right way to use lasers. Right?

Wrap Up

Today’s puzzle felt a bit like a variation on the pipe maze from day 12, but way less tricky in terms of part 2. I can’t really envision what a more efficient approach to “find the laser that hits the most cells” is than just simulating what happens with each laser and picking the maximum. Perhaps the fine folks over at r/adventofcode have come up with something. I did get to play around with inheritance today. Since I don’t do much OO normally, it felt a little awkward, but “when in a Java-adjacent language” and all that. I’m happy to wrap this one up a bit earlier than expected for a Saturday puzzle and looking forward to tomorrow.

Advent of Code 2023 - Day 15

Fri, 15 Dec 2023 00:00:00 +0000

Day 15 - Lens Library

Find the problem description HERE.

The Input - What Parsing?


class Day15(input: String) {

    // It feels like there should be more to it than this...
    private val parsed = input.split(",").map { it.replace("\n", "") }.toList()
    
}

Yep, that’s it. Moving on. (I don’t actually think there were any newlines in there, but the text explicitly said to ignore them, so I’m not taking any chances.)

Part One - Making a Hash of It

Here we are, hanging out with a nervous reindeer, preparing (I assume) to utilize all that awesome light energy from the parabolic mirror array. We’re geared up with our PPI and ready to rock and roll! And then, there’s this manual… Looks like we need to HASH our initialization sequence (the input) and add up the results to make sure we did it right. Now, just to verify we did it correctly. Hey, where’d that reindeer go?


/**
 * Hashes a string to an integer using the described hashing algorithm
 *
 * This is what the puzzle told me to do!
 *
 * @param str The string to hash.
 * @return An integer derived from hashing the string
 */
fun hash(str: String): Int =
    str.fold(0) { acc, char -> ((acc + char.code) * 17) % 256 }

class Day15(input: String) {

    // private val parsed = ...

    // OK so far. Hash all the input strings into an Int and return
    // the summed result.
    fun solvePart1(): Int = parsed.sumOf { hash(it) }
    
}

Part one describes this simple hashing algorithm and asks us to implement it. So, that’s exactly what I did. Following instructions is nice, sometimes. Unfortunately, having a part one this simple can only mean one thing…

Part Two - It’s a Trap!

Well, not a trap, really. It’s more like all the usual steps we take, including parsing the input, got shoved into part two. Now we need to use our simple hashing algorithm from part one to configure an array of boxes of lenses to power up mah lazerz in the correct sequence. For power! (probably) Let’s get started.


// fun hash(str: String): Int = ...


/**
 * This class represents one of the lenses
 *
 * @property label The label on the lens.
 * @property focalLength The focal length of the lens.
 */
data class Lens(val label: String, val focalLength: Int) {
    /**
     * Indicates whether the given label belongs to this lens
     *
     * @param label The label to check.
     * @return Does the label match the label on this lens?
     */
    fun hasLabel(label: String): Boolean = label == this.label
}

/**
 * Convenience!
 */
fun List<Lens>.boxed(): LensBox = LensBox(this)

/**
 * This class represents a box of lenses, in order
 *
 * @property lenses The lenses in this box, in order.
 */
data class LensBox(val lenses: List<Lens>) {
    companion object {
        /**
         * Create a new, empty [LensBox]
         *
         * @return An empty box for lenses.
         */
        fun new(): LensBox = LensBox(listOf())
    }

    /**
     * Remove a lens from the box by checking labels
     *
     * If there's no lens in the box with the given label, then that just makes
     * your job easier!
     *
     * @param label The label to check.
     * @return A copy of this [LensBox] without the offending lens.
     */
    fun removeByLabel(label: String): LensBox =
        lenses.filter { !it.hasLabel(label) }.boxed()

    /**
     * Insert a lens into the box
     *
     * If there's already a lens with the new lens' label, replace the old
     * lens with the new lens. Otherwise, append the new lens to the end of
     * the list of lenses.
     *
     * @param lens The new lens to add.
     * @return A copy of this [LensBox] with the new lens added.
     */
    fun insert(lens: Lens): LensBox {
        val containsLens = lenses.any { it.hasLabel(lens.label) }
        return if (containsLens) {
            lenses.map { if (it.hasLabel(lens.label)) lens else it }.boxed()
        } else {
            LensBox(lenses + lens)
        }
    }
}

/**
 * This class represents the full array of 256 [LensBox]es
 *
 * @property lensBoxes All the boxes for lenses.
 */
data class LensBoxArray(val lensBoxes: MutableList<LensBox>) {
    companion object {
        /**
         * Create an array of 256 empty boxes for lenses
         *
         * @return An empty [LensBoxArray]
         */
        fun new(): LensBoxArray =
            LensBoxArray(MutableList(256) { LensBox.new() })
    }

    /**
     * Remove the lens with the given label from its box
     *
     * The box to insert the lens into is determined by hashing this label.
     *
     * @param label The label of the lens to remove
     */
    fun remove(label: String) {
        val idx = hash(label)
        lensBoxes[idx] = lensBoxes[idx].removeByLabel(label)
    }

    /**
     * Insert a lens into its box
     *
     * The box to insert the lens into is determined by hashing its label.
     *
     * @param lens The lens to insert
     */
    fun insert(lens: Lens) {
        val idx = hash(lens.label)
        lensBoxes[idx] = lensBoxes[idx].insert(lens)
    }

    /**
     * Calculate the total focusing power of this array of boxes
     *
     * Each lens in a box contributes (box idx + 1) * (slot idx + 1) * focal length.
     *
     * @return The total focusing power of all boxes in this [LensBoxArray].
     */
    fun focusingPower(): Int {
        return lensBoxes.withIndex().sumOf { (idx, box) ->
            val boxNumber = idx + 1
            box.lenses.withIndex().sumOf { (idx, lens) ->
                val slot = idx + 1
                lens.focalLength * slot * boxNumber
            }
        }
    }
}

/**
 * This class represents a parsed operation from the input
 *
 * Turns out the input is a comma-separated list of operations to perform
 * on a [LensBoxArray]. Each operation is either an 'insert' spelled like
 * '<label>=<focal length>' or a 'remove' spelled like '<label>-'. An 'insert'
 * operation indicates that the lens specified should be inserted into the
 * [LensBoxArray] and a 'remove' operation indicates that the lens with the
 * specified label should be removed from the [LensBoxArray].
 */
sealed class Operation {
    // The two variants of [Operation]
    data class InsertLens(val lens: Lens) : Operation()
    data class RemoveLens(val label: String) : Operation()

    companion object {
        /**
         * Parse an [Operation] variant from a portion of the input file
         *
         * @param string The string to parse.
         * @return An operation parsed from the string.
         */
        fun fromString(string: String): Operation {
            return if (string.contains('=')) {
                val (label, focalLengthStr) = string.split('=')
                val focalLength = focalLengthStr.toInt()
                val lens = Lens(label, focalLength)
                InsertLens(lens)
            } else {
                val label = string.removeSuffix("-")
                RemoveLens(label)
            }
        }
    }

    /**
     * Perform this operation on a [LensBoxArray]
     *
     * Performs the operation defined by this variant of [Operation] on
     * the given [LensBoxArray]. Mutates the [LensBoxArray] in place.
     *
     * @param lensBoxArray The [LensBoxArray] to perform this operation on.
     */
    fun perform(lensBoxArray: LensBoxArray) {
        when (this) {
            is InsertLens -> lensBoxArray.insert(this.lens)
            is RemoveLens -> lensBoxArray.remove(this.label)
        }
    }
}

class Day15(input: String) {

    // private val parsed = ...

    // OK so far. Hash all the input strings into an Int and return
    // the summed result.
    fun solvePart1(): Int = parsed.sumOf { hash(it) }

    // Ah-HA! Part 2 was the whole enchilada today, including the "real parsing
    // of the input. Turns out, each of the comma-separated strings is an
    // instruction for an operation to perform on an array of 256 boxes of
    // lenses. For part 2, we _really_ parse the input into operations, create
    // a representation of the empty array of boxes, then simulate the result
    // of performing all the operations on the box array, in order. Finally,
    // we sum the "focusing power" of all the lenses in all the boxes for our
    // answer.
    fun solvePart2(): Int {
        val lensBoxArray = LensBoxArray.new()
        val operations = parsed.map(Operation::fromString)
        operations.forEach { it.perform(lensBoxArray) }
        return lensBoxArray.focusingPower()
    }
    
}

I agree, there probably was a simpler way to set up the Operations, but I kinda wanted to try adding methods to sealed class variants. And now I did it!

Wrap Up

This was a fun little exercise in making a kinda-sorta hashmap. I may point folks to this exercise who are working on learning more about how this data structure works (in a simplified way). I tried a couple of new Kotlin things as well. I have to say, I keep trying to shoehorn Rust Enums and Traits into other languages, and it keeps not working. That’s sort of what I was going for with today’s sealed class. In hindsight, I’m thinking maybe some sort of Operation superclass with subclasses for InsertLens and RemoveLens would have been more ‘object-oriented’. It definitely seems a little awkward to have that dispatch function in the main Operation class. Live and learn!

Advent of Code 2023 - Day 14

Thu, 14 Dec 2023 00:00:00 +0000

Day 14 - Parabolic Reflector Dish

Find the problem description HERE.

The Input - We All Have A Platform

Today is another “grid-from-text” input, which we’re pretty well familiar with by this point. The one big “twist” here is that there are three different kinds of tiles (’.’, ‘#’, and ‘O’). Still, grid to list-of-lists, here we come!


/**
 * This enum represents each possible shape on our platform
 *
 * @property rep The character representation of the enum variant
 */
enum class MapTile(private val rep: Char) {
    EMPTY('.'), SQUARE('#'), ROUND('O');

    companion object {
        /**
         * Parse a [MapTile] from a character
         *
         * @param char The character to parse.
         * @return The [MapTile] representation of `char`.
         */
        fun fromChar(char: Char): MapTile {
            return when (char) {
                '.' -> EMPTY
                '#' -> SQUARE
                'O' -> ROUND
                else -> throw Exception("$char does not represent a map tile!")
            }
        }
    }

    /**
     * Produce a string representation of this [MapTile]
     *
     * @return A string representing this [MapTile].
     */
    override fun toString(): String {
        return rep.toString()
    }
}

/**
 * This class represents the state of the large metal platform
 *
 * @property grid The configuration of rocks on the platform.
 */
data class Platform(val grid: List<List<MapTile>>) {
    companion object {
        /**
         * Parse a [Platform] from the input file
         *
         * @param input The character grid from the input file.
         * @return The [Platform] parsed from the input.
         */
        fun fromInput(input: List<List<Char>>): Platform {
            val rotatedInput = input.rotateClockwise()
            val grid = rotatedInput.map { row -> row.map(MapTile::fromChar) }
            return Platform(grid)
        }
    }
}


class Day14(input: List<List<Char>>) {

    // Today's input is a grid of characters that needs to be treated like a
    // big metal platform with rolling and stationary rocks.
    private val parsed = Platform.fromInput(input)
    
}

Now that we’ve been re-platformed, it’s time to get tilted!

Part One - Rolling Stones

In today’s puzzle, we’re (I think) planning to adjust a large mirror array by rolling rocks around on a large metal platform with (what I assume to be) strategically placed obstacles. This seems like maybe not the best way to manage complex mirror alignments, but I’m no astrologist, so what do I know?


// enum class MapTile(private val rep: Char) { ... }

/**
 * Rotate a rectangular grid
 *
 * Transforms a rectangular grid (list of lists) as shown below:
 *
 *   [[1, 2, 3],            [[7, 4, 1],
 *    [4, 5, 6],     ->      [8, 5, 2],
 *    [7, 8, 9]]             [9, 6, 3]]
 *
 * @return A copy of the original grid, rotated one quarter turn clockwise.
 */
fun <T> List<List<T>>.rotateClockwise(): List<List<T>> {
    if (isEmpty() || first().isEmpty()) return this

    val numRows = this.size
    val numCols = first().size

    return List(numCols) { col ->
        List(numRows) { row ->
            this[numRows - 1 - row][col]
        }
    }
}

data class Platform(val grid: List<List<MapTile>>) {
    companion object {
    
        // fun fromInput(input: List<List<Char>>): Platform { ... }
    
        /**
         * Roll the round rocks to the end of the line
         *
         * This function accepts a line representing a row or column from
         * the platform and rolls all the round rocks from the start of the
         * line towards the end, as far as they will go.
         *
         * @param line A list of [MapTile]s representing a row or column on the
         * platform.
         * @return A copy of the input list with the round rocks rolled as far
         * as they will go from beginning to end.
         */
        private fun tiltToEnd(line: List<MapTile>): List<MapTile> {
            val output = line.toMutableList()
            var lastOpenIdx = output.size   // The index a rock can roll to

            // Walking backwards from the end of the line...
            for (currentIdx in output.lastIndex downTo 0) {
                when (output[currentIdx]) {
                    // If we're currently checking an empty tile and we haven't
                    // found an empty tile to roll a rock to yet...
                    MapTile.EMPTY -> {
                        if (lastOpenIdx == output.size) lastOpenIdx = currentIdx
                    }

                    // If we're checking a square rock, then the next possibly
                    // empty tile will be the tile before the square rock.
                    MapTile.SQUARE -> lastOpenIdx = currentIdx - 1

                    // If we're checking a round rock...
                    MapTile.ROUND -> {
                        if (lastOpenIdx == currentIdx) {
                            // ...and there's no open position to move it to,
                            // treat it like a square rock and set the next
                            // possibly open index to the tile before this rock.
                            lastOpenIdx -= 1
                        } else if (lastOpenIdx < output.size) {
                            // ...and there's an open position to move it to,
                            // move the round rock to that open position and
                            // mark the tile before the destination as a
                            // possibly open tile.
                            output[lastOpenIdx] = MapTile.ROUND
                            output[currentIdx] = MapTile.EMPTY
                            lastOpenIdx -= 1
                        }
                    }
                }
            }

            return output
        }
        
        /**
         * Calculate the load of a line of [MapTile]s
         *
         * The load of a line of [MapTile]s is the sum of the 1-indexed indices
         * occupied by round rocks. For example, a round rock in the fifth
         * position adds 5 to the load.
         *
         * @param line A list of [MapTile]s representing a row or column on the
         * platform.
         * @return The calculated load of the line.
         */
        private fun calculateLoad(line: List<MapTile>): Int =
            line.withIndex().filter { (_, tile) -> tile == MapTile.ROUND }
                .sumOf { (idx, _) -> idx + 1 }
    }
    
    /**
     * Produce a copy of this [Platform] tilted towards the end
     *
     * The 'end' of a platform is defined by the individual rows in the `grid`.
     * The last index of the grid is the 'end', and rocks will roll that
     * direction. In order to roll the rocks North, the grid should be rotated
     * such that the last index in each row of the grid is the North end.
     *
     * @return A copy of this [Platform] with rocks rolled towards the end.
     */
    fun tiltToEnd(): Platform = grid.map(Platform::tiltToEnd).toPlatform()

    /**
     * Calculate the load of this [Platform]
     *
     * As with the tilt, load is calculated oriented towards the 'end' of
     * the [Platform], which is based on the orientation of the underlying grid.
     * To get the load on the North pillar, the North end of the grid must be
     * oriented towards the end.
     *
     * @return The load on the end of this [Platform].
     */
    fun calculateLoad(): Int = grid.sumOf(Platform::calculateLoad)
    
}

/**
 * Converts a grid of [MapTile]s to a [Platform]
 *
 * This function extends the functionality of a [List<List<MapTile>>], adding
 * a `toPlatform` function that converts the grid of [MapTile]s into a
 * [Platform].
 *
 * @return The converted [Platform].
 */
fun List<List<MapTile>>.toPlatform(): Platform = Platform(this)

class Day14(input: List<List<Char>>) {

    // private val parsed = ...

    // Tilt the platform to the north and calculate the load on the northern
    // pillar.
    fun solvePart1(): Int = parsed.tiltToEnd().calculateLoad()
    
}

I’m not going to lie, I was pretty pleased with myself for that tilting algorithm! Tilting an entire platform in O(n * m) seemed like it should be possible, and it really was! This contrasts to yesterday where my attempt at O(n) mirror detection flopped. Progress!

Part Two - Spread the Load

Well, this is fair. It would honestly be kind of weird if we were able to adjust the mirror correctly by just shoving all the rocks in one direction. Again, what an excellent engineering setup! In part two we need to determine what the maximum load on the north pillar would be after a billion iterations of tilting the platform in all four cardinal directions. You know, I bet there’s a way to figure this out without actually tilting a billion times…


// enum class MapTile(private val rep: Char) { ... }

// fun <T> List<List<T>>.rotateClockwise(): List<List<T>> { ... }

data class Platform(val grid: List<List<MapTile>>) {
    companion object {
    
        // fun fromInput(input: List<List<Char>>): Platform { ... }
    
        // private fun tiltToEnd(line: List<MapTile>): List<MapTile> { ... }
        
        // private fun calculateLoad(line: List<MapTile>): Int = ...
    }
    
    // fun tiltToEnd(): Platform = ...

    // fun calculateLoad(): Int = ...
    
    /**
     * Conduct a full cycle of tilting and rotating the [Platform]
     *
     * Tilts the platform, rolling all rocks towards the end, then rotates
     * the platform clockwise one quarter turn. Repeat for all four cardinal
     * directions, until the returned [Platform] is oriented in the same
     * direction as this one was to begin with.
     *
     * @return A copy of this [Platform] tilted and rotated through a full cycle.
     */
    fun tiltFullCycle(): Platform {
        var grid = grid

        repeat(4) {
            grid = grid.map(Platform::tiltToEnd)
            grid = grid.rotateClockwise()
        }

        return Platform(grid)
    }
    
}

class Day14(input: List<List<Char>>) {

    // private val parsed = ...

    // fun solvePart1(): Int = parsed.tiltToEnd().calculateLoad()
    
    // There's no way we're actually supposed to do a billion cycles. There
    // must be a better way!
    fun solvePart2(): Int {
        var cyclesRemaining = 1_000_000_000
        var platform = parsed

        // First, check how many cycles it takes to see a platform
        // configuration appear twice. This indicates a repeating sequence!
        val seenStates = mutableSetOf<Platform>()
        while (!seenStates.contains(platform)) {
            seenStates.add(platform)
            platform = platform.tiltFullCycle()
            cyclesRemaining -= 1
        }

        // Now, we know where the repeating sequence starts, we need to
        // determine how long the sequence is. Reset our seen states and
        // keep cycling the platform until we finish another repeating
        // sequence.
        val repeatingSequenceStart = cyclesRemaining
        seenStates.clear()
        while (!seenStates.contains(platform)) {
            seenStates.add(platform)
            platform = platform.tiltFullCycle()
            cyclesRemaining -= 1
        }

        // Armed with the knowledge of how many states are in the
        // repeating sequence...
        val repeatingSequenceLength = repeatingSequenceStart - cyclesRemaining

        // ... we can make a list of the loads of each of those states. Now
        // we know all the possible load values that can appear from here on
        // out. But which one? Well...
        val repeatingSequenceLoads = mutableListOf<Int>()
        repeat(repeatingSequenceLength) {
            platform = platform.tiltFullCycle()
            repeatingSequenceLoads.add(platform.calculateLoad())
            cyclesRemaining -= 1
        }

        // Assume the sequence repeats over and over. Eventually, we'll run out
        // of cycles on the platform. So, the number of cycles left after the
        // last full repeating sequence tells us which of the load values
        // to use.
        val cyclesRemainingAfterLastSequence =
            cyclesRemaining % repeatingSequenceLength
        return repeatingSequenceLoads[cyclesRemainingAfterLastSequence - 1]
    }
}

Remember Day 17 from last year, Pyroclastic Flow? Yeah, that’s what this reminds me of. Thankfully, we really didn’t need to spin this thing a billion times. The repeated stress would probably have made it collapse!

Wrap Up

This was a good day! Granted, I did have the advantage of having seen a similar problem last year, but really, that’s a big part of what solving coding puzzles comes down to: pattern recognition. It’s one of the reasons that I encourage others to give Advent of Code a go. Being exposed to a variety of problems and solutions trains your brain to recognize when similar problems arise in other puzzles (and even sometimes in real life) and gives you a push in the right direction, even if you don’t remember exactly how that previous problem went. Good stuff.

Advent of Code 2023 - Day 13

Wed, 13 Dec 2023 00:00:00 +0000

Day 13 - Point of Incidence

Find the problem description HERE.

The Input - Mirror, Mirror

Well, the input is interesting today, but only because it’s one of the few times I can recall getting an input with multiple grids separated by a blank line. What’s really interesting is that each row/columns is a list of what essentially amounts to true/false values… or… 1’s and 0’s? Yep, each row/column can be represented as a number where the set bits are ‘#’ characters and the unset bits are ‘.’ characters (or, the other way around, really). At first I just left them as strings, but I found that converting them to numbers actually made debugging easier in this puzzle.



/**
 * Transposes a rectangular matrix
 *
 * This function extends the functionality of a [List<List<T>>] by adding a
 * `transpose` function which returns a transposed copy of the original
 * list of lists. All the sub-lists must be the same length. For example:
 *
 *  [[1, 2, 3],             [[1, 4, 7],
 *   [4, 5, 6],     ->       [2, 5, 8],
 *   [7, 8, 9]]              [3, 6, 9]]
 *
 *  @return The transposed list of lists.
 */
fun <T> List<List<T>>.transpose(): List<List<T>> {
    if (isEmpty() || this.any { it.size != this[0].size }) {
        throw IllegalArgumentException("Inner lists must have the same size")
    }

    return List(this[0].size) { col ->
        List(size) { row ->
            this[row][col]
        }
    }
}

/**
 * Converts a String to an Integer by interpreting it as a binary value
 *
 * This function extends the functionality of [String] by adding a `toBinary`
 * function that interprets the characters in the string as 1's and 0's then
 * converts it to the [Int] represented by the binary string.
 *
 * @param one The character to interpret as 1.
 * @param zero The character to interpret as 0.
 * @return The String as binary and converted to an Int.
 */
fun String.toBinary(one: Char = '#', zero: Char = '.'): Int =
    toList().joinToString("") { char ->
        when (char) {
            one -> "1"
            zero -> "0"
            else -> {
                throw Exception("$char has not be specified as either '1' or '0'!")
            }
        }
    }.toInt(radix = 2)


/**
 * The class represents one of the patterns of the landscape with a mirror
 *
 * @property rows Integer representations of the rows in the pattern.
 * @property cols Integer representations of the columns in the pattern.
 */
data class LandscapePattern(val rows: List<Int>, val cols: List<Int>) {
    companion object {
        /**
         * Parses a [LandscapePattern] from a chunk of the input file
         *
         * @param input A chunk of the input file.
         * @return A [LandscapePattern].
         */
        fun fromInputChunk(input: List<String>): LandscapePattern {
            // Each row and column is represented as an integer where the binary
            // of the integer corresponds to the input string (either row-wise
            // or column-wise), with '#' -> 1 and '.' -> 0. This honestly
            // was as much to make debugging easier as for efficiency.
            val rows = input.map { it.toBinary() }
            val cols = input.map { it.toList() }.transpose()
                .map { it.joinToString("").toBinary() }

            return LandscapePattern(rows, cols)
        }
    }
}

class Day13(input: List<List<String>>) {

    // Parse each grid in the input file into a [LandscapePattern]
    private val parsed =
        input.filter { it.isNotEmpty() }.map(LandscapePattern::fromInputChunk)
}

As a note, sometimes when I write helper functions like the ones above that seem really useful, I’ll try to make them as generic as possible so that they can possibly be re-used in a future day’s puzzle.

Part One - Walk This Way

From steampunk to post-apocalyptic. To think, this all began because we wanted more snow. Remember that? Yep, we’re still on the same fetch-quest. For today’s puzzle, we need to identify which bits of the landscape are being reflected from giant mirrors in a land of ash and rocks so we can find our way through. Let’s do it!


data class LandscapePattern(val rows: List<Int>, val cols: List<Int>) {
    companion object { 
    
      // fun fromInputChunk(input: List<String>): LandscapePattern { ... }
    
      /**
         * Checks for a line of symmetry in a list of lines
         *
         * Each `line` is a row or column from one of the inputs. This function
         * checks `checkIdx` to determine whether it represents the left (or
         * top) row (or column) in a line of symmetry, meaning the lines on one
         * side of the line are a mirror image of the other side, all the way
         * to the edge of the input chunk.
         *
         * @param lines A list of rows or columns (as integers).
         * @param checkIdx The index in the list to check for symmetry.
         * @return A flag indicating whether the indicated index sits to
         * the left (or top) of a line of symmetry.
         */
        private fun hasLineOfSymmetry(
            lines: List<Int>,
            checkIdx: Int
        ): Boolean {
            require(0 <= checkIdx && checkIdx < lines.size) {
                throw Exception("There is no row $checkIdx in ${lines}!")
            }

            // Last line can't be a line of symmetry
            if (checkIdx == lines.size - 1) return false

            // If there is a line of symmetry, the given index will be to the
            // left of it in the list of lines.
            var leftIdx = checkIdx
            var rightIdx = checkIdx + 1

            // So long as the two lines being checked are the same, we expand
            // the mirrored region until one side of it reaches past the
            // beginning or end of the list of lines.
            while (lines[leftIdx] == lines[rightIdx]) {
                leftIdx--; rightIdx++ // Step the indices out by one
                if (leftIdx < 0 || rightIdx >= lines.size) return true
            }

            // If we reach a point where the two lines being checked aren't
            // equal, and we're still inside the list of lines, then we know
            // this index isn't where the line of symmetry is.
            return false
        }
    }

    /**
     * Summarize this [LandscapePattern] for my notes
     *
     * A pattern is summarized by finding the line of symmetry, counting the
     * number of rows to the left (or columns above) and returning that number
     * (* 100 for rows).
     *
     * @return The summary value for this [LandscapePattern].
     */
    fun summarize(): Int {
        // Search for a horizontal line of symmetry, returning the
        // number of lines above it * 100 if found.
        for (idx in rows.indices) {
            val adjacentToMirror = hasLineOfSymmetry(rows, idx)
            if (adjacentToMirror) return (idx + 1) * 100
        }

        // Search for a vertical line of symmetry, returning the number of
        // lines to the left of it if found.
        for (idx in cols.indices) {
            val adjacentToMirror = hasLineOfSymmetry(cols, idx)
            if (adjacentToMirror) return idx + 1
        }

        // Pitch a fit if no mirror is found.
        throw Exception("Could not find a mirror for $this!")
    }
}
    
class Day13(input: List<List<String>>) {

    // Parse each grid in the input file into a [LandscapePattern]
    // private val parsed = ...

    // For each [LandscapePattern] find the mirror, calculate the summary
    // value, and return the sum. 
    fun solvePart1(): Int = parsed.sumOf { it.summarize() }
    
}

The basic strategy here is to pick an index (row or column) and just walk outwards a pair of values at a time, checking to be sure the values are equal (aka, “mirrored”). This wasn’t the first strategy I tried. Early on, I was being too clever and trying to detect mirrors in an O(n) way whereas this approach is more O(n^2) per LandscapePattern, but the patterns themselves are small enough that this still runs pretty quickly and, importantly, it actually works!

Part Two - Achilles Smudge

After bashing our face into a mirror, we realize that each and every grid contains exactly one flaw. That’s oddly specific, but we can figure out how to deal with it. As it turns out, this was an especially infuriating twist, not because it was hard to deal with, but when I was inspecting the input grids to figure out why my code wasn’t working initially, I kept finding these “off-by-one” reflections and throwing myself off. Turns out, it was intentional!


enum class MirrorDetectionStrategy { ALL_MIRRORED, ONE_SMUDGE }

data class LandscapePattern(val rows: List<Int>, val cols: List<Int>) {
    companion object {
        // fun fromInputChunk(input: List<String>): LandscapePattern { ... }

        // private fun hasLineOfSymmetry(lines: List<Int>, checkIdx: Int): Boolean { ... }
        
         /**
         * Checks for a line of symmetry, accounting for one smudge
         *
         * The difference between this function and `hasLineOfSymmetry` is that
         * this function allows one, and only one, pair of lines to differ by
         * one bit.
         *
         * @param lines A list of rows or columns (as integers).
         * @param checkIdx The index in the list to check for symmetry.
         * @return A flag indicating whether the indicated index sits to
         * the left (or top) of a line of symmetry.
         */
        private fun hasLineOfSymmetryWithSmudge(
            lines: List<Int>,
            checkIdx: Int
        ): Boolean {
            require(0 <= checkIdx && checkIdx < lines.size) {
                throw Exception("There is no row $checkIdx in ${lines}!")
            }
            if (checkIdx == lines.size - 1) return false

            var leftIdx = checkIdx
            var rightIdx = checkIdx + 1

            // Need to keep track of whether we've already cleaned a smudge
            var cleanedSmudge = false

            // The `bitdiff` result is the number of bits different between the
            // two lines being examined. A value of zero would mean the two are
            // the same and a value of one is an acceptable smudge.
            // As long as the two lines being checked have zero or one smudges...
            while (lines[leftIdx] bitdiff lines[rightIdx] <= 1) {
                // This pair contains a smudge
                if (lines[leftIdx] bitdiff lines[rightIdx] == 1) {
                    // If we've already cleaned a smudge, there's no line of
                    // symmetry here.
                    if (cleanedSmudge) break

                    // Note the cleaned smudge. This can't happen again.
                    cleanedSmudge = true
                }
                leftIdx--; rightIdx++  // Step the indices out by one

                // If we reach either end of the lines, return whether or
                // not we cleaned one smudge. If no smudges were cleaned,
                // there is no line of symmetry.
                if (leftIdx < 0 || rightIdx >= lines.size) return cleanedSmudge
            }
            return false
        }
    }
    
    /**
     * Summarize this [LandscapePattern] for my notes
     *
     * A pattern is summarized by finding the line of symmetry, counting the
     * number of rows to the left (or columns above) and returning that number
     * (* 100 for rows).
     *
     * @param strategy The strategy to use when determining whether or not a
     * particular row/column is adjacent to a mirror.
     * @return The summary value for this [LandscapePattern].
     */
    fun summarize(strategy: MirrorDetectionStrategy): Int {
        // Search for a horizontal line of symmetry, returning the
        // number of lines above it * 100 if found.
        for (idx in rows.indices) {
            val adjacentToMirror = when (strategy) {
                MirrorDetectionStrategy.ALL_MIRRORED -> hasLineOfSymmetry(
                    rows,
                    idx
                )

                MirrorDetectionStrategy.ONE_SMUDGE -> hasLineOfSymmetryWithSmudge(
                    rows,
                    idx
                )
            }
            if (adjacentToMirror) return (idx + 1) * 100
        }

        // Search for a vertical line of symmetry, returning the number of
        // lines to the left of it if found.
        for (idx in cols.indices) {
            val adjacentToMirror = when (strategy) {
                MirrorDetectionStrategy.ALL_MIRRORED -> hasLineOfSymmetry(
                    cols,
                    idx
                )

                MirrorDetectionStrategy.ONE_SMUDGE -> hasLineOfSymmetryWithSmudge(
                    cols,
                    idx
                )
            }
            if (adjacentToMirror) return idx + 1
        }

        // Pitch a fit if no mirror is found.
        throw Exception("Could not find a mirror for $this!")
    }
}

class Day13(input: List<List<String>>) {

    // Parse each grid in the input file into a [LandscapePattern]
    // private val parsed = ...

    // For each [LandscapePattern] find the mirror, calculate the summary
    // value, and return the sum. The ALL_MIRRORED pattern means that
    // mirrors are detected by having a perfect reflection across a line of
    // symmetry all the way to one edge of the grid.
    fun solvePart1(): Int =
        parsed.sumOf { it.summarize(MirrorDetectionStrategy.ALL_MIRRORED) }

    // For each [LandscapePattern] find the mirror, calculate the summary
    // value, and return the sum  The ONE_SMUDGE pattern means that
    // mirrors are detected by having a reflection _with exactly one incorrect
    // value_ (a smudge) across a line of symmetry all the way to one edge of
    // the grid.
    fun solvePart2(): Int =
        parsed.sumOf { it.summarize(MirrorDetectionStrategy.ONE_SMUDGE) }
}

In a rare move, I actually modified my part one code a bit to accommodate the forced application of the strategy pattern to this puzzle. Why? Because it seemed like a fun thing to practice!

Wrap Up

I really enjoyed today’s puzzle, in part because (through my own tunnel vision) it threw me down a bit of a rabbit hole trying to debug an algorithm that I just couldn’t get to work. So, I had a chance to step back and re-consider my approach. It ended up being a good reminder that premature optimization can be a bad thing and end up costing you valuable time. I’m also pretty please with how this code turned out, so there’s that as well.

Advent of Code 2023 - Day 12

Tue, 12 Dec 2023 00:00:00 +0000

Day 12 - Hot Springs

Find the problem description HERE.

The Input - Oh My Pun!

Today we have a relatively simple input for a deceptively difficult problem. Let’s start with the input, though. We have multiple lines where each line is split in half (by a single space every time, thankfully). The left half depicts different spring in different conditions and the right half indicates the sizes of known sizes of damaged groups. Oh, also, “Hot Springs”. Get it?


/**
 * This enum represents the different states a spring
 *
 * @property rep The character that represents this enum variant.
 */
enum class Condition(val rep: Char) {
    DAMAGED('#'), OPERATIONAL('.'), UNKNOWN('?');

    companion object {
        fun fromChar(char: Char): Condition {
            return when (char) {
                '#' -> DAMAGED
                '.' -> OPERATIONAL
                '?' -> UNKNOWN
                else -> throw IllegalArgumentException("Cannot represent '$char' as a [Condition]!")
            }
        }
    }
}

/**
 * This class represents the condition record of a single row of springs.
 * 
 * @property springs A list of the conditions of the springs.
 * @property damagedGroups A list of known sizes of damaged groups.
 */
data class ConditionRecord(
    val springs: List<Condition>, val damagedGroups: List<Int>
) {
    companion object {
        // Parse the input lines!
        fun fromString(str: String): ConditionRecord {
            val (conditionStr, groupStr) = str.split(" ").map { it.trim() }
            val conditions = conditionStr.map(Condition::fromChar)
            val groups = groupStr.split(",").map { it.toInt() }
            return ConditionRecord(conditions, groups)
        }
    }
}

class Day12(input: List<String>) {

    private val parsed =
        input.filter { it.isNotEmpty() }.map(ConditionRecord::fromString)

}

Not too much to say about parsing today. LOTS to say about solving the puzzle, though.

Part One - Novel Algorithm

In part one, our goal is to figure out which springs are damaged, armed with the knowledge of which springs might be damaged and how large all the damaged groups are. My first instinct was to try a depth-first search over the springs, and honestly, it might have taken that approach less time to run than it took me to type through my explanation for the dynamic programming approach I ended up taking. See, I had an inkling that I was dealing with overlapping sub-problems, and I was right! Now, on to the lengthy explanation!

Example 1: .???.### 1,1,3

Note, my examples trim all the ‘.’ from the original puzzle input and prepend one ‘.’. I’m not sure this is 100% necessary, but it made it easier for me to think through. In this example, we have three groups of damaged springs (of lengths 1, 1, and 3) and 8 total springs, of which 2 are operational (’.’), 3 are damaged (’#’), and the remaining 3 are unknown (’?’). The essence of the DP approach here is to repeatedly calculate the number of possible combinations of springs under sets of increasing constraints, which are, in order:

no damaged springs
one damaged group of Damaged Groups[0] length
the first and second damaged groups
all three damaged groups

For this example, I’ll walk through them one constraint at a time.

First Constraint: No Damaged Groups

 Damaged Groups: []
 Starting Conditions  :    [., ?, ?, ?, ., #, #, #]
 Possible Combinations: [1, 1, 1, 1, 1, 1, 0, 0, 0]
                        /   |  |  |  |  |   \
                       a    b  c  d  e  f    g

Note, the list of possible combinations is one longer than the list of springs, and is offset from the spring list by -1 as we walk through. This means that the first value in the list represents the number of possible ways to construct an empty list of springs with the given groups (in this case, none). Conveniently, there is one way to construct an empty list, so the value at (a) is 1.

The second value, (b) is also 1, because it is possible to construct a row with one operational spring when there are no damaged springs The values at (c-f) are similarly 1, because there is only one way a spring can be constructed of ‘.???.’ springs with no damage, which is ‘…..’.

On the other hand, (g) must be 0, because it is not possible to construct a row with one damaged section if there are no damaged springs allowed. This carries forward to the rest of the list, since ‘…..#’ and ‘…..#?’ are equally impossible.

Second Constraint: One group of one damaged section

In this second round, we are required to construct a row with one group of damaged springs consisting of only a single spring. It is important here to remember that each group of damaged springs must be separated by at least one operational section.

 Groups: [1]
 Starting Conditions  :    [., ?, ?, ?, ., #, #, #]
 Possible Combinations: [1, 1, 1, 1, 1, 1, 0, 0, 0] with no groups
 Possible Combinations: [0, 0, 1, 2, 3, 3, 1, 0, 0] add group of 1
                        /  /   |  |  |  |  |   \
                       a  b    c  d  e  f  g    h

With a group length of 1, the pattern is readily recognized as current[i] = current[i - 1] + (previous[i - 2] ?: 0). I’m using the ?: notation here to indicate ‘zero if index out of bounds’.

We see that (a, b) are zero, which makes sense because you can’t construct a row with a 1-wide defect from ’’ or ‘.’. ‘.?’ (c) could be ‘.#’, so there’s one possible configuration at this point that meets our criteria. ‘.??’ (d) could be ‘.#.’ or ‘..#’ and ‘.???’ (e) could be ‘.#..’, ‘..#.’, or ‘…#’. (f) is the same as (e) with an extra operational section at the end.

(g) and (h) break the pattern, though because ‘#’ is a damaged spring, which constrains our options for assigning the damaged group. At (g), there’s only one way to assign a 1-wide group of damage, and at (h) there’s more damage than we can accommodate. Notably, the value at (h) would be the same if the springs were ‘.???.#?’ as well. This means we need to keep up with the width of the damaged groups up to our current position and determine when we can’t carry over combinations that were available up to the current point. This would be when either the current group size is larger than the run of possibly damaged springs or the spring just prior to where the group would start is also DAMAGED (which would make the actual damaged group too large). The logic goes like this:

      damage can fit = group size <= run of DAMAGED and UNKNOWN
                   AND spring just prior to group start point is not DAMAGED
      current[i] = if current section is not DAMAGED and damage can fit:
          (A) current[i - 1] + (previous[i - 2] ?: 0)
      else if current section is DAMAGED and damage can fit:
          (B) (previous[i - 2] ?: 0)
      else if current section is not DAMAGED:
          (C) current[i - 1]
      else:
          (D) 0

That final else applies if the current spring is DAMAGED and the group size is larger than the current run of DAMAGED and UNKNOWN springs.

Third Constraint: Two groups of 1 damaged spring each

 Groups: [1, 1]
 Starting Conditions  :    [., ?, ?, ?, ., #, #, #]
 Possible Combinations: [1, 1, 1, 1, 1, 1, 0, 0, 0] with no groups
 Possible Combinations: [0, 0, 1, 2, 3, 3, 1, 0, 0] add group of 1
 Possible Combinations: [0, 0, 0, 0, 1, 1, 3, 0, 0] add group of 1
                              /   |  |  |  |   \
                             a    b  c  d  e    f

Here, we see that (a) is behaving as expected. At (a), the run of possible damaged springs is 1 and the spring there is not damaged, so branch (A) of our logic applies, yielding 0. The same is true for (b-d). Logically, we can see that there’s only one way to distribute two 1-wide damage regions into ‘.???.’, which is ‘.#.#.’. Recall that the damaged groups must be separated by an operational spring.

(e) is interesting because the spring there is damaged, which ties up one of the damage groups and, again logically, we see that this means that the other group of damaged springs can be distributed three different ways, as ‘.#…#’, ‘..#..#’, or ‘…#.#’. Because the section at (e) is damaged and the current group can fit in the run, this uses branch (B) of our logic above.

(f) is a spring that is DAMAGED and the spring just prior to the group start area is also DAMAGED (which would make a two-wide DAMAGED region), so branch (D) applies.

Third Constraint: Two groups of 1 and one group of 3 DAMAGED springs

 Groups: [1, 1, 3]
 Starting Conditions  :    [., ?, ?, ?, ., #, #, #]
 Possible Combinations: [1, 1, 1, 1, 1, 1, 0, 0, 0] with no groups
 Possible Combinations: [0, 0, 1, 2, 3, 3, 1, 0, 0] add group of 1
 Possible Combinations: [0, 0, 0, 0, 1, 1, 3, 0, 0] add group of 1
 Possible Combinations: [0, 0, 0, 0, 0, 0, 0, 0, 1] add group of 3
                                    /         |   \
                                   a          b    c

Our options are much more limited now, needing to add a 3-wide DAMAGED group on top of the two 1-wide groups. This means that when we reach section (a), we’ll only have space for either the two 1-wide groups or or the one 3-wide group, but not both. At point (a), considering the three-wide group, the current spring is not DAMAGED and we do have enough room to insert the group, so we take branch (B) of our logic.

At section (b), the spring is damaged and we do not have space to insert our 3-wide DAMAGED group, so we take branch (D). Finally, at section (c), the section is DAMAGED and we do have space for our 3-wide group, so we take branch (B). Except, now branch (B) would yield a result of 0, but we can clearly see that there’s one way to arrange all three DAMAGED groups: ‘.#.#.###’. If we examine the logic of branch (B), we can see that with the first two groups, we were selecting the number of possible combinations containing the previous groups at the point before we were inserting the current group. Making a slight modification yields the final algorithm:

      damage can fit = group size <= run of DAMAGED and UNKNOWN
                   AND spring just prior to group start point is not DAMAGED
      current[i] = if current section is not DAMAGED and damage can fit:
          (A) current[i - 1] + (previous[i - (group size + 1)] ?: 0)
      else if current section is DAMAGED and damage can fit:
          (B) (previous[i - (group size + 1)] ?: 0)
      else if current section is not DAMAGED:
          (C) current[i - 1]
      else:
          (D) 0

The code below will follow this logic, with some minor indexing tweaks to account for the fact that we can’t really shift the row of springs representation over by one index as we did when visualizing these examples.

I encourage you to apply the logic above to this second example of a row of springs from today’s example input if you’re not 100% clear on how it works yet.

Example 2: .?###???????? 3,2,1

 Damaged Groups: [3, 2, 1]
 Starting Conditions  :    [., ?, #, #, #, ?, ?, ?, ?, ?, ?, ?, ?]
 Possible Combinations: [1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]  with no groups
 Possible Combinations: [0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]  add group of 3
 Possible Combinations: [0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 5, 6]  add group of 2
 Possible Combinations: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 3, 6, 10] add group of 1

And now, let’s turn that logic into actual code!


// enum class Condition(val rep: Char) { ... }


data class ConditionRecord(
    val springs: List<Condition>, val damagedGroups: List<Int>
) {
    // companion object { ... }

    fun countAllPossibleConditions(): Long {
        // The list of conditions should start with _one_ OPERATIONAL
        // spring in order to support the algorithm for counting possible
        // combinations of conditions. Excess OPERATIONAL springs at the
        // beginning are removed.
        val springs = mutableListOf(Condition.OPERATIONAL)
        springs.addAll(this.springs.dropWhile { it == Condition.OPERATIONAL })

        // Note, the first value in this list does not correspond to the first
        // section, but to a hypothetical 'empty' section preceding the list
        // of springs. This means there is exactly 1 possible
        // configuration for an empty list of springs.
        var possibleCombinations = MutableList(springs.size + 1) { 1L }

        // Starting with the first DAMAGED section all the way to the end,
        // set the number of possible combinations to zero, because there is
        // no way to make a spring with damaged springs if there is no
        // damage (our starting constraint).
        //
        //      Starting Conditions  :    [., ?, ?, ?, ., #, #, #]
        //      Possible Combinations: [1, 1, 1, 1, 1, 1, 0, 0, 0]
        for ((idx, _) in springs.withIndex()
            .dropWhile { (_, c) -> c != Condition.DAMAGED }) {
            possibleCombinations[idx + 1] = 0
        }

        // For each group size of damaged springs, we successively build upon
        // the previous set of possible constraints, determining how many
        // combinations are possible after adding each group as a constraint.
        for (checkedGroupSize in damagedGroups) {
            // Each new 'layer' of possibilities starts out empty.
            val nextPossibleCombinations =
                MutableList(springs.size + 1) { 0L }
            var possiblyDamagedRunSize = 0

            for ((idx, condition) in springs.withIndex().drop(1)) {
                // Reset the 'group' of possibly DAMAGED springs to consider if
                // we encounter an OPERATIONAL section.
                if (condition == Condition.OPERATIONAL) {
                    possiblyDamagedRunSize = 0
                } else {
                    possiblyDamagedRunSize += 1
                }

                // Here is where we implement our logic described exhaustively
                // above:

                // damage can fit = group size <= run of DAMAGED and UNKNOWN
                //              AND section just prior to group insertion point is not DAMAGED
                // current[i] = if current section is not DAMAGED and damage can fit:
                //     (A) current[i - 1] + (previous[i - (group size + 1)] ?: 0)
                // else if current section is DAMAGED and damage can fit:
                //     (B) (previous[i - (group size + 1)] ?: 0)
                // else if current section is not DAMAGED:
                //     (C) current[i - 1]
                // else:
                //     (D) 0
                val groupCanFit = possiblyDamagedRunSize >= checkedGroupSize
                val precedingIdx = (idx - checkedGroupSize).coerceAtLeast(0)
                val notContiguousDamage =
                    springs[precedingIdx] != Condition.DAMAGED
                val isNotDamaged = condition != Condition.DAMAGED
                val damageCanFit = groupCanFit && notContiguousDamage
                nextPossibleCombinations[idx + 1] =
                    if (isNotDamaged && damageCanFit) {
                        nextPossibleCombinations[idx] + possibleCombinations[precedingIdx]
                    } else if (condition == Condition.DAMAGED && damageCanFit) {
                        possibleCombinations[precedingIdx]
                    } else if (isNotDamaged) {
                        nextPossibleCombinations[idx]
                    } else {
                        0L
                    }
            }

            // Update the 'current' layer
            possibleCombinations = nextPossibleCombinations
        }

        // Update the number of possible combinations with the result of
        // determining possible combinations with the current group
        // of DAMAGED springs.
        return possibleCombinations.last()
    }
}


class Day12(input: List<String>) {

    // private val parsed = ...

    fun solvePart1(): Long = parsed.sumOf { it.countAllPossibleConditions() }

}

Yes, I know that’s a lot of comments in addition to the book that was this section. I told you it took a long time to write.

Part Two - The Spring Has Sprung

I have excellent news! We’re back to misunderstanding documentation! And, thankfully, it was just the text and not the method. Both the springs and the lists of damaged groups are 5 times longer than we thought. No big deal!


// enum class Condition(val rep: Char) { ... }


data class ConditionRecord(
    val springs: List<Condition>, val damagedGroups: List<Int>
) {
    // companion object { ... }

    // fun countAllPossibleConditions(): Long { ... }
    
    fun unfold(): ConditionRecord {
        val conditions =
            listOf(springs + Condition.UNKNOWN).repeating().asSequence()
                .take(5).flatMap { it }.toMutableList().dropLast(1)
        val damagedGroups =
            listOf(damagedGroups).repeating().asSequence().take(5)
                .flatMap { it }.toList()
        return ConditionRecord(conditions, damagedGroups)
    }
}


class Day12(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Long = ...

    fun solvePart2(): Long =
        parsed.sumOf { it.unfold().countAllPossibleConditions() }

}

Nah, I don’t have much to say about this one. Used up all my words today.

Wrap Up

Dynamic programming is hard! And, for me at least, it’s harder to explain than it is to do. Today was certainly good practice in both regards, though. I don’t think I used any new Kotlin-specific goodies, which is probably a good thing.

Advent of Code 2023 - Day 11

Mon, 11 Dec 2023 00:00:00 +0000

Day 11 - Cosmic Expansion

Find the problem description HERE.

The Input - Galaxy Brain

Back to 2D maps, are we? Well, I came prepared today. I added another input pre-processing function to read in a 2D grid like this as a List<List<Char>>. It’s not much, but it’s a nice convenience to have on the front-end. After that, I think all I’ll need is a list of where the galaxies are and lists of which rows/columns from the input I need to expand. Let’s get that done.


/**
 * This class represents a position on our map of galaxies.
 *
 * @property row The row of this position.
 * @property col The col of this position.
 */
data class Position(val row: Int, val col: Int) {
    /**
     * Calculate the Manhattan distance between two Positions
     *
     * @param other The other position to calculate distance to.
     * @return The Manhattan distance to the `other` position.
     */
    fun manhattanDistanceTo(other: Position): Int {
        return abs(row - other.row) + abs(col - other.col)
    }
}

/**
 * This class represents the map of galaxies from the input
 *
 * @property galaxies A list of [Position]s of galaxies on the map.
 * @property expandedRows A list of the row indices in the map with no galaxies.
 * @property expandedCols A list of the column indices in the map with no 
 * galaxies.
 */
data class GalaxyMap(
    val galaxies: List<Position>,
    val expandedRows: List<Int>,
    val expandedCols: List<Int>
) {
    companion object {
        /**
         * Parse the input file into a [GalaxyMap]
         *
         * @param input The grid of characters from the input file.
         * @return A [GalaxyMap] parsed from the input.
         */
        fun fromInput(input: List<List<Char>>): GalaxyMap {
            // Every '#' is a galaxy. Everything else is just empty space.
            val galaxies = input.withIndex()
                .flatMap { (rowIdx, row) ->
                    row.withIndex().map { (colIdx, char) ->
                        char to Position(
                            rowIdx,
                            colIdx
                        )
                    }
                }
                .filter { (char, _) -> char == '#' }
                .map { (_, position) -> position }

            // It seemed most straightforward to start with a set of all row
            // and column indices, then remove any row or column with a galaxy
            // on it.
            val expandedRows = input.indices.toMutableSet()
            val expandedCols = input.first().indices.toMutableSet()
            galaxies.forEach { position ->
                expandedRows.remove(position.row)
                expandedCols.remove(position.col)
            }

            // I'm sorting the expanded rows and columns lists here so that I
            // can binary search them later for _max velocity_.
            return GalaxyMap(
                galaxies,
                expandedRows.toList().sorted(),
                expandedCols.toList().sorted()
            )
        }
    }
}

class Day11(input: List<List<Char>>) {

    // Let's map the galaxy!
    private val parsed = GalaxyMap.fromInput(input)
    
}

That wasn’t too painful. I feel like I’m getting more fluent with the available iterator chaining functions from the standard library, which is a nice benefit. Now, let’s map this galaxy for real!

Part One - The One That Got Away

So, I guess we decided we didn’t have time to go track that random robot critter down and… I don’t know, interrogate it about where to find parts? Probably a good call to just move on, but I’m keeping my eye out for that thing to randomly reappear in another puzzle. Probably for us to play dice with or some such. As for the task at hand, it looks like if we can help this elvish astronomer calculate some astronomical distances, he’ll lead us to the hot springs. Sounds like a real winner to me!


import kotlin.math.abs

// data class Position(val row: Int, val col: Int) { ... }

data class GalaxyMap(
    val galaxies: List<Position>,
    val expandedRows: List<Int>,
    val expandedCols: List<Int>
) {
    // companion object { ... }

    /**
     * Count the number of expanded rows between two galaxies
     *
     * Because the expanded rows are sorted, we can binary search to determine
     * how many expanded rows are between two rows that we know aren't in the
     * list (because they have galaxies on them).
     *
     * @param galaxyA The first galaxy in the pair.
     * @param galaxyB the other galaxy in the pair.
     * @return The number of expanded rows between the pair of galaxies.
     */
    private fun expandedRowsBetween(galaxyA: Position, galaxyB: Position): Int =
        abs(
            expandedRows.binarySearch(galaxyA.row) - expandedRows.binarySearch(
                galaxyB.row
            )
        )

    /**
     * Count the number of expanded columns between two galaxies
     *
     * Because the expanded columns are sorted, we can binary search to determine
     * how many expanded columns are between two columns that we know aren't in
     * the list (because they have galaxies on them).
     *
     * @param galaxyA The first galaxy in the pair.
     * @param galaxyB the other galaxy in the pair.
     * @return The number of expanded columns between the pair of galaxies.
     */
    private fun expandedColsBetween(galaxyA: Position, galaxyB: Position): Int =
        abs(
            expandedCols.binarySearch(galaxyA.col) - expandedCols.binarySearch(
                galaxyB.col
            )
        )

    /**
     * Calculate the real distance between two galaxies
     *
     * The distance between two galaxies consists of their Manhattan distance
     * on the map, plus the expansion of the universe that occurred during
     * the time it took the light to travel to our observation point. This
     * is accomplished by doubling the "width" of rows and columns without
     * any galaxies on them.
     *
     * @param galaxyA The first galaxy.
     * @param galaxyB The second galaxy.
     * @return The distance between the two galaxies.
     */
    fun distanceBetween(galaxyA: Position, galaxyB: Position): Int {
        val observedDistance = galaxyA.manhattanDistanceTo(galaxyB)
        val rowExpansions = expandedRowsBetween(galaxyA, galaxyB)
        val colExpansions = expandedColsBetween(galaxyA, galaxyB)

        // Because each expanded row/columns counts as 2, and because we already
        // accounted for each of them once in the `observedDistance`, we just
        // add the "extra width" of 1 for each expanded row/column to our final
        // distance.
        return observedDistance + rowExpansions + colExpansions
    }
}

/**
 * Returns a sequence of non-repeating pairs of elements in a list
 *
 * This extension function defines a sequence of pairs of elements from the
 * original list such that all unique pairs are generated. For this purpose,
 * the pairs (A, B) and (B, A) are considered equivalent.
 *
 * @return A sequence of non-repeating pairs of elements in [List<T>].
 */
fun <T> List<T>.pairs(): Sequence<Pair<T, T>> =
    sequence {
        for (i in indices) {
            for (j in i + 1 until size) {
                yield(this@pairs[i] to this@pairs[j])
            }
        }
    }


class Day11(input: List<List<Char>>) {

    // private val parsed = ...

    // In part one, the galaxy has a static expansion. Since the "shortest path"
    // through empty space is just the distance, calculate the distance between
    // all unique pairs of galaxies and return the sum.
    fun solvePart1(): Int =
        parsed.galaxies.pairs().sumOf { (galaxyA, galaxyB) ->
            parsed.distanceBetween(galaxyA, galaxyB)
        }
}

I’m not going to lie, I’m a big fan of that extension function on a List<T> that returns a sequence over that list. I feel like that’s going to come in handy in future days, so I’m pretty excited to have found it today. Oddly, or at least, oddly to me, I tried to write an iterator at first, but found I needed to call .toSequence() on the iterator to include it in a chain of method calls. I felt like I should have been able to use it without, but maybe I just misunderstood the difference between iterators and sequences in Kotlin. More to learn, I guess, which is a good reason to keep going!

Part Two - The Final Frontier

Of course the actual input evaluation is different that we originally thought. At least this time, it’s not because we read the instructions too quickly or failed to look at the back or some other nonsense, it was someone else’s mistake! Sweet vindication! Thankfully, we have everything we need from part one to adapt to this relatively minor change.


import kotlin.math.abs

// data class Position(val row: Int, val col: Int) { ... }

data class GalaxyMap(
    val galaxies: List<Position>,
    val expandedRows: List<Int>,
    val expandedCols: List<Int>
) {
    // companion object { ... }

    // private fun expandedRowsBetween(
    //    galaxyA: Position, 
    //    galaxyB: Position
    // ): Int = ...

    // private fun expandedColsBetween(
    //    galaxyA: Position, 
    //    galaxyB: Position
    // ): Int = ...

    // fun distanceBetween(galaxyA: Position, galaxyB: Position): Int { ... }

    /**
     * Calculate the real distance between two galaxies with variable expansion
     *
     * The distance between two galaxies consists of their Manhattan distance
     * on the map, plus the expansion of the universe that occurred during
     * the time it took the light to travel to our observation point. For part
     * two, the examples are for smaller levels of expansion than the expected
     * answer, so this function accepts the multiple by which the empty rows
     * and columns have expanded as a parameter.
     *
     * @param galaxyA The first galaxy.
     * @param galaxyB The second galaxy.
     * @param expansionFactor The multiple by which the empty rows/columns have
     * expanded.
     * @return The distance between the two galaxies.
     */
    fun enhancedDistanceBetween(
        galaxyA: Position,
        galaxyB: Position,
        expansionFactor: Int
    ): Long {
        val observedDistance = galaxyA.manhattanDistanceTo(galaxyB)

        // We multiply the number of rows/columns by the expansionFactor - 1
        // because, once again, the one-wide row/column is already accounted
        // for in the `observedDistance`.
        val rowExpansions =
            expandedRowsBetween(galaxyA, galaxyB) * (expansionFactor - 1)
        val colExpansions =
            expandedColsBetween(galaxyA, galaxyB) * (expansionFactor - 1)
        return observedDistance.toLong() + rowExpansions.toLong() + colExpansions.toLong()
    }
}

// fun <T> List<T>.pairs(): Sequence<Pair<T, T>> = ...


class Day11(input: List<List<Char>>) {

    // private val parsed = ...

    // fun solvePart1(): Int = ...

    // In part two, we need to accommodate a variable expansion factor if we want
    // to use the same function for testing the example and real inputs (we do
    // want to do that, by the way).
    fun solvePart2(expansionFactor: Int): Long =
        parsed.galaxies.pairs().sumOf { (galaxyA, galaxyB) ->
            parsed.enhancedDistanceBetween(galaxyA, galaxyB, expansionFactor)
        }
}

This was an interesting part two in that we didn’t actually get an example answer with the real expansion factor. Thankfully, it was straightforward enough to include it as a parameter and calculate the example results and our answer with the same function.

Wrap Up

Today’s puzzle was interesting. Don’t think I didn’t catch all those “shortest distance” references trying to trick me into writing a breadth-first search (or, God forbid, Dijkstra’s!) to find the distance between stars. To be honest, the line in one of the partial examples is what really gave it away. Also, sequences are awesome! Had fun, learned some more Kotlin. What more could you ask for?

Advent of Code 2023 - Day 10

Sun, 10 Dec 2023 00:00:00 +0000

Day 10 - Pipe Maze

Find the problem description HERE.

The Input - Loop the Loop

Today’s puzzle had a serious amount of parsing, which is really more along the lines of what I’d expect from a weekend at this point in the calendar. On the plus side, it made sense to me to use a builder pattern for building up our input one step at a time today.


/**
 * This class represents a location in a grid of PipeTiles
 *
 * @param row The row of this location in a grid of PipeTiles
 * @param col The column of this location in a grid of PipeTiles
 */
data class Location(val row: Int, val col: Int) {
    fun toTheSouth(): Location = Location(row + 1, col)
    fun toTheNorth(): Location = Location(row - 1, col)
    fun toTheWest(): Location = Location(row, col - 1)
    fun toTheEast(): Location = Location(row, col + 1)
}

/**
 * This class represents a tile in the grid of pipes.
 *
 * Each tile is accessible via two different directions: north, south,
 * east, or west. The exceptions are tiles with no pipe, which aren't
 * accessible via any direction, and the default value for the start,
 * which is accessible in any direction. This will need to be corrected
 * before tracing the loop of pipes.
 *
 * @property north Is this tile accessible via the north?
 * @property south Is this tile accessible via the south?
 * @property east Is this tile accessible via the east?
 * @property west Is this tile accessible via the west?
 */
data class PipeTile(
  var north: Boolean, 
  var south: Boolean, 
  var east: Boolean, 
  var west: Boolean
) {
    companion object {
        fun default(): PipeTile = PipeTile(false, false, false, false)

        fun start(): PipeTile = PipeTile(true, true, true, true)

        /**
         * Produce a [PipeTile] from a character.
         *
         * Maps the characters from the input file to the corresponding [PipeTile].
         *
         * @param char The character to map.
         * @return The corresponding [PipeTile].
         */
        fun fromChar(char: Char): PipeTile {
            return when (char) {
                '|' -> PipeTile(north = true, south = true, east = false, west = false)
                '-' -> PipeTile(north = false, south = false, east = true, west = true)
                'L' -> PipeTile(north = true, south = false, east = true, west = false)
                'J' -> PipeTile(north = true, south = false, east = false, west = true)
                '7' -> PipeTile(north = false, south = true, east = false, west = true)
                'F' -> PipeTile(north = false, south = true, east = true, west = false)
                '.' -> default()
                'S' -> start()
                else -> throw IllegalArgumentException(
                  "$char does not represent a valid pipe section!"
                )
            }
        }
    }
}

/**
 * Represents a two-dimensional grid of [PipeTile]s
 *
 * @property grid A two-dimensional array containing [PipeTile]s.
 */
data class PipeGrid(val grid: List<List<PipeTile>>) {

    val rows: Int get() = grid.size
    val cols: Int get() = grid.first().size

    /**
     * Override indexing operations so that the values in the grid can be
     * accessed directly via [Location]. This operation includes bounds-checking,
     * and will return a representation of an empty tile space for an attempt to
     * access a location outside the grid.
     *
     * @param location The location of the tile to access.
     */
    operator fun get(location: Location): PipeTile {
        val (row, col) = location
        val indexOutOfBounds = (row < 0 || row >= rows || col < 0 || col >= cols)
        return if (indexOutOfBounds) PipeTile.default() else grid[row][col]
    }
}

/**
 * Provides a builder interface for producing a [PipeMap].
 *
 * Starting with the input file data, this class provides an API for
 * building up a [PipeMap] one step at a time.
 */
data class PipeMapBuilder(
    var grid: PipeGrid? = null,
    var start: Location? = null,
    var loopTiles: HashMap<Location, Int>? = null
) {
    /**
     * Read in the input file and fill in the [PipeGrid]
     *
     * @param input The list of lines from the input file.
     * @return The partially completed [PipeMapBuilder] with grid added.
     */
    fun readInputToGrid(input: List<String>): PipeMapBuilder {
        grid = PipeGrid(input.map { line ->
            line.map { char -> PipeTile.fromChar(char) }
        })

        return this
    }

    /**
     * Identify the starting location of the [PipeGrid].
     *
     * Iterate through the grid tiles and pick out the starting Location. The
     * starting [PipeTile] will need to be corrected from the default starting
     * configuration based on its surrounding tiles.
     *
     * @return The partially completed [PipeMapBuilder] with starting location added.
     */
    fun identifyStartLocation(): PipeMapBuilder {
        val grid = grid ?: 
          throw Exception("Must establish grid before identify start location.")

        // Find the starting location.
        var startRow = 0
        var startCol = 0
        loop@ for ((rowIdx, row) in grid.grid.withIndex()) {
            for ((colIdx, pipe) in row.withIndex()) {
                if (pipe == PipeTile.start()) {
                    startRow = rowIdx
                    startCol = colIdx
                    break@loop
                }
            }
        }
        val startLocation = Location(startRow, startCol)

        // Correct the start location to identify which directions are actually valid
        val startPipe = PipeTile(true, true, true, true)
        if (startPipe.north && !grid[startLocation.toTheNorth()].south) {
          grid[startLocation].north = false
        }
        if (startPipe.south && !grid[startLocation.toTheSouth()].north) {
          grid[startLocation].south = false
        }
        if (startPipe.east && !grid[startLocation.toTheEast()].west) {
          grid[startLocation].east = false
        }
        if (startPipe.west && !grid[startLocation.toTheWest()].east) {
          grid[startLocation].west = false
        }
        start = startLocation

        return this
    }

    /**
     * Trace the loop of pipes attached to the start location.
     *
     * Perform a breadth-first search through the pipes, producing a mapping
     * of location to the number of steps that location is from the start.
     *
     * @return The partially completed [PipeMapBuilder] with completed `loopTiles`.
     */
    fun tracePipeLoop(): PipeMapBuilder {
        val grid = grid ?: 
          throw Exception("Must establish grid before identify start location.")
        val start = start ?: 
          throw Exception("Must identify starting location before tracing the pipe loop!")

        // We'll walk through using a Breadth-first search, so that we can walk away
        // from the starting location in both directions at the same time.
        val queue = ArrayDeque(listOf(0 to start))
        val seenLocations: HashMap<Location, Int> = HashMap<Location, Int>()

        // So long as there are tiles left to visit...
        while (queue.isNotEmpty()) {
            // Get the last location from the queue and add it to the
            // mapping of seen locations to number of steps taken, unless
            // we've already been there. That's probably not a concern with
            // this puzzle, but it's good practice.
            val (steps, location) = queue.removeLast()
            if (seenLocations.contains(location)) continue
            seenLocations[location] = steps

            // Add all the neighbors that haven't been visited yet to the queue.
            for (neighbor in grid.getNeighborsOf(location)) {
                if (seenLocations.contains(neighbor)) continue
                queue.addFirst(steps + 1 to neighbor)
            }
        }

        loopTiles = seenLocations

        return this
    }

    /**
     * Finalize the [PipeMapBuilder] into a [PipeMap]
     *
     * @return A [PipeMap] with all the non-null properties of the [PipeMapBuilder].
     */
    fun toPipeMap(): PipeMap {
        val grid = grid ?: 
          throw Exception("Must establish grid before finalizing.")
        val start = start ?: 
          throw Exception("Must identify starting location before finalizing.")
        val loopTiles = loopTiles ?: 
          throw Exception("Must identify loop tiles before finalizing.")
        return PipeMap(grid, start, loopTiles)
    }


}

/**
 * Represents a finalized [PipeMap].
 */
data class PipeMap(
    val grid: PipeGrid,
    var start: Location,
    var loopTiles: HashMap<Location, Int>
) 

class Day10(input: List<String>) {

    // It's my first builder pattern in Kotlin!
    private val parsed = PipeMapBuilder()
      .readInputToGrid(input)
      .identifyStartLocation()
      .tracePipeLoop()
      .toPipeMap()

}

Okay, to be fair, there’s a good amount of the code that will eventually be used to solve part one in there. Thing is, it didn’t make sense to walk over all the pipe tiles in order to identify which ones were in the loop without counting the steps while we did it. So, with this, we should pretty much be done with part one, right?

Part One - Critter Chaser

In a strange and alien environment, a tiny robot flees into a tangle of pipes. Obviously, we need to go after it! But, we need to be smart about it. First, we’ll figure out how far away from us it could possibly be by determining the maximum number of steps any piece of pipe could be from the starting location.


// data class Location(val row: Int, val col: Int) { ... }

// data class PipeTile(
//   var north: Boolean, 
//   var south: Boolean, 
//   var east: Boolean, 
//   var west: Boolean
// ) { ... }


// data class PipeGrid(val grid: List<List<PipeTile>>) { ... }

// data class PipeMapBuilder(
//     var grid: PipeGrid? = null,
//     var start: Location? = null,
//     var loopTiles: HashMap<Location, Int>? = null
// ) { ... }

/**
 * Represents a finalized [PipeMap].
 */
data class PipeMap(
    val grid: PipeGrid,
    var start: Location,
    var loopTiles: HashMap<Location, Int>
) {
    /**
     * Return the maximum number of steps to any tile from the starting location.
     *
     * @return The maximum number of steps.
     */
    fun stepsToFurthestPointFromStart(): Int {
        return loopTiles.values.max()
    }
}


class Day10(input: List<String>) {

    // private val parsed = ...

    // In part one, we chase a furry critter through a loop of pipes.
    fun solvePart1(): Int = parsed.stepsToFurthestPointFromStart()
}

Yeah, I’ll admit that most of the work was done by the parsing on this one. Unfortunately, that doesn’t really hold true for part two…

Part Two - Enhance!

Having chased the “animal” into the tangled nest of pipes, we find it has eluded us. It probably has a nest somewhere! Clearly, disturbing this thing in its nest is likely to lead to us getting the machine parts we came for and not multiple lacerations from mechanical critter teeth. The thing is, our original map representation is poorly suited for determining which tiles are completely enclosed in the loop of pipes because it’s too compact. By expanding the map’s resolution, we can reliably determine which tiles can be accessed by walking between pipes (and thust excluded from our final count.)


// data class Location(val row: Int, val col: Int) { ... }

data class PipeTile(
  var north: Boolean, 
  var south: Boolean, 
  var east: Boolean, 
  var west: Boolean
) {
    // companion object { ... }

    /**
     * Expands a [PipeTile] from a 1x1 to a 3x3 representation.
     *
     * Expands this [PipeTile] so that it can occupy a 3x3 grid area for filling
     * the tiles outside the loop in part two. Each direction that was accessible
     * from the [PipeTile] now contains a corresponding PIPE variant, while the
     * other tiles are PASSABLE. For example, if '#' is PIPE and '-' is PASSABLE,
     * then the following transformations would apply:
     *
     *         ---             -#-             -#-             ---
     *  '7' -> ##-      'J' -> ##-      '|' -> -#-      '-' -> ###
     *         -#-             ---             -#-             ---
     *
     * @return An [ExpandedMapTile]
     */
    fun expand(): List<List<ExpandedMapTile>> {
        val pipes = MutableList(3) { MutableList(3) { ExpandedMapTile.PASSABLE } }
        pipes[1][1] = ExpandedMapTile.PIPE
        if (north) pipes[0][1] = ExpandedMapTile.PIPE
        if (south) pipes[2][1] = ExpandedMapTile.PIPE
        if (east) pipes[1][2] = ExpandedMapTile.PIPE
        if (west) pipes[1][0] = ExpandedMapTile.PIPE
        return pipes
    }
}

// data class PipeGrid(val grid: List<List<PipeTile>>) { ... }

// data class PipeMapBuilder(
//     var grid: PipeGrid? = null,
//     var start: Location? = null,
//     var loopTiles: HashMap<Location, Int>? = null
// ) { ... }

// data class PipeMap(
//     val grid: PipeGrid,
//     var start: Location,
//     var loopTiles: HashMap<Location, Int>
// ) { ... }

/**
 * Represents a tile type in the [ExpandedPipeMap]
 */
enum class ExpandedMapTile {
    EMPTY,      // Nothing there
    PASSABLE,   // A passable tile next to a pipe
    PIPE,       // An impassable pipe tile
    OUTER,      // An empty tile outside the pipe loop
}

/**
 * Represents an expansion of the [PipeMap] for counting inner loop tiles.
 *
 * In Part two, we need to identify tiles _inside_ the loop of the pipes, which
 * means all tiles completely enclosed by the loop. The original grid makes
 * it difficult to determine which tiles are able to be traveled to from outside
 * the loop. By exapanding each original tile from a 1x1 to a 3x3 configuration,
 * we can walk the grid between the pipes.
 *
 * @param grid A two-dimensional grid of [ExpandedMapTile]s.
 */
data class ExpandedPipeMap(var grid: MutableList<MutableList<ExpandedMapTile>>) {
    companion object {
        /**
         * Expands a [PipeMap] into an [ExpandedPipeMap].
         *
         * @param pipeMap The [PipeMap] to expand.
         * @return The expanded pipe map.
         */
        fun fromPipeMap(pipeMap: PipeMap): ExpandedPipeMap {
            // Expand all the original [PipeTile]s.
            val expansions =
                pipeMap.loopTiles.keys.map { 
                  location -> location to pipeMap.grid[location].expand() 
                }

            // For each expanded tile, transfer the [ExpandedPipeTile] variants to
            // correct location in a grid three times the size of the original grid.
            val grid = MutableList(pipeMap.grid.rows * 3) {
              MutableList(pipeMap.grid.cols * 3) { ExpandedMapTile.EMPTY } 
            }

            // For each [ExpandedPipeTile] in each expansion, transfer it to the
            // appropriate location int the expanded grid.
            for ((location, expansion) in expansions) {
                val (originalRow, originalCol) = location
                for ((rowIdx, row) in expansion.withIndex()) {
                    val newRow = (originalRow * 3) + rowIdx
                    for ((colIdx, isPipe) in row.withIndex()) {
                        val newCol = (originalCol * 3) + colIdx
                        grid[newRow][newCol] = isPipe
                    }
                }
            }

            return ExpandedPipeMap(grid)
        }
    }

    val rows: Int get() = grid.size
    val cols: Int get() = grid.first().size

    /**
     * Indicates whether the given location is accessible in the grid.
     *
     * In the expanded grid, a neighbor is accessible if it is in the grid
     * and it _isn't_ a PIPE tile.
     *
     * @param location The [Location] to check.
     * @return Whether the location is accessible
     */
    private fun isAccessible(location: Location): Boolean {
        if (location.row < 0 || location.row >= rows) return false
        if (location.col < 0 || location.col >= cols) return false
        if (grid[location.row][location.col] == ExpandedMapTile.PIPE) return false
        return true
    }

    /**
     * An updated function for finding neighbors in this new expanded grid.
     *
     * @param location The location to get neighbors for.
     * @return A list of accessible neighbor locations.
     */
    private fun getNeighborsOf(location: Location): List<Location> {
        val (row, col) = location
        val neighbors = mutableListOf<Location>()
        if (isAccessible(Location(row - 1, col))) neighbors.add(Location(row - 1, col))
        if (isAccessible(Location(row + 1, col))) neighbors.add(Location(row + 1, col))
        if (isAccessible(Location(row, col - 1))) neighbors.add(Location(row, col - 1))
        if (isAccessible(Location(row, col + 1))) neighbors.add(Location(row, col + 1))
        return neighbors
    }

    /**
     * Count the tiles enclosed by the loop of pipe.
     *
     * In part two, we identify the tiles that _aren't_ enclosed in
     * the loop by "flood-filling" from an identified outside tile. How
     * was this starting tile identified? Visual inspection of the input!
     *
     * @return The number of tiles enclosed.
     */
    fun countInnerTiles(): Int {
        // Flood fill to populate the list of seen locations. Perform a
        // breadth-first search starting from a known outside tile and
        // convert any tile found into an OUTSIDE tile.
        val queue = ArrayDeque(listOf(Location(0, 0)))
        val seenLocations: HashSet<Location> = HashSet<Location>()

        while (queue.isNotEmpty()) {
            val location = queue.removeLast()
            if (seenLocations.contains(location)) continue
            seenLocations.add(location)

            // Mark the found tile as an OUTER tile
            val (row, col) = location
            grid[row][col] = ExpandedMapTile.OUTER

            // Check each neighbor that hasn't been visited yet.
            for (neighbor in this.getNeighborsOf(location)) {
                if (seenLocations.contains(neighbor)) continue
                queue.addFirst(neighbor)
            }
        }

        // Return a count of all the EMPTY tiles. The total count is
        // divided by 9, because expanding a [PipeTile] to an [ExpandedMapTile]
        // increases the number of grid spaces by a factor of 9.
        return (grid.sumOf { row -> row.count { it == ExpandedMapTile.EMPTY } }) / 9
    }
}


class Day10(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Int = ...

    // In part two we increase the resolution of the map to make it possible
    // to flag all the OUTER tiles, leaving the EMPTY tiles as the inner tiles.
    fun solvePart2(): Int = ExpandedPipeMap.fromPipeMap(parsed).countInnerTiles()
}

There’s quite a bit of code there, and I really hope the comments are sufficient to explain what’s going on here.

Wrap Up

Today was a doozy! Not so much from the perspective of solving the puzzle, but just the sheer amount of code I wrote to parse, and then re-parse the parsed input into an expanded format. Granted, from the perspective of “learning Kotlin”, it was a good opportunity to write more code. And, I got to test-drive the builder pattern (even though it may not have been completely necessary). A lot of code on a weekend isn’t anything to get upset about either. All told, it was a good day!

Advent of Code 2023 - Day 09

Sat, 09 Dec 2023 00:00:00 +0000

Day 9 - Mirage Maintenance

Find the problem description HERE.

The Input - Read the Room

Today’s puzzle has us reading off lists of numbers from some fancy gadget we just happen to have in our pocket for checking environmental readings of oases. Sounds complicated, but it’s really lines of space-separated numbers. This, we can handle.


class Day09(input: List<String>) {

    // List of space-separated strings to list of lists of numbers,
    // coming up!
    private val parsed = input.map { line -> line.split(" ").map { it.toInt() }}
    
}

That’s it? Yeah, that’s going to be today’s theme, didn’t you hear?

Part One - Getting to the Bottom of Things

Looks like we’ve finally had a chance to rest, relax, and prepare for the next exciting leg of this journey. Good. We needed a bit of a break. Speaking of getting a break, part one of today’s puzzle has us reading in a series of numbers, finding the next number in series, then adding up all the ’next numbers’. It’s some environmental stuff, so I hear. Thankfully, it’s a straightforward recursive solution.

/**
 * Return the next number in the sequence.
 *
 * This is likely a very brittle approach (meaning the possibility of
 * recursing too deeply for generic lists of numbers), but for these
 * specially crafted sensor readings, it works just fine. This function
 * recursively generates the list of differences and adds the next
 * forecasted value from that list to the last value of the current list.
 *
 * @return The next forecasted value for this sequence of readings.
 */
fun List<Int>.nextSequenceValue(): Int {
    // Base case. No need to go to all zeros, oncw the sequence contains
    // all values the same, we know what the next value will be.
    if (this.all { it == this[0] }) return this[0]

    // Get the differences between each pair of values in `sequence`.
    val derivedSequence = this.windowed(2) { (left, right) -> right - left }
    return this.last() + derivedSequence.nextSequenceValue()
}

class Day09(input: List<String>) {

    // private val parsed = ...

    // In part one, we sum the next number in sequence for each list.
    fun solvePart1(): Int = parsed.sumOf { it.nextSequenceValue() }
}

Why, yes, there is more comment than code here. How very astute of you to notice!

Part Two - Where Do You Come From, Where Do You Go?

Well, yes, I suppose it would be handy to know what the previous sensor value for each of these readings is. Granted, I dont’ know what each of these readings represents, so the value may be a bit limited, but more data is always better, right? I sure hope so!


// fun List<Int>.nextSequenceValue(): Int { ... }

class Day09(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Int = ...
    
    // In part two, we extrapolate each list _backwards_ by one, then sum
    // those results.
    fun solvePart2(): Int = parsed.sumOf { it.reversed().nextSequenceValue() }
}

I think I’m going to go back to bed today!

Wrap Up

It feels like today’s puzzle was a bit of a break after yesterday’s, although truth be told yesterday’s puzzles wasn’t that bad if you recalled the fondness of Advent of Code for problems with cyclical values. None of that today, though. Just do what the puzzle text says, earn stars, and move on. I wonder if this day was here to remind us all that directions and puzzles are two different things, and that one of those things is more fun than the other… Either way, I think I’ll enjoy having the free time back today and spend it on something productive and festive. Happy Holidays!

Advent of Code 2023 - Day 08

Fri, 08 Dec 2023 00:00:00 +0000

Day 8 - Haunted Wasteland

Find the problem description HERE.

The Input - Mapping The Network Fantastic

Today’s input offers a bit of a twist, with two distinct sections, but the lines of each part are pretty simple, so we won’t have any issues there. I considered trying to map the input into a tree-based structure with nodes that pointed to each other, but it seemed like it might be a bit of a pain to make sure all the nodes got added, there might be cycles, etc. So, I opted for a simpler String > (left, right) kind of structure that I thought I might change out in refactoring. Turns out, that was the right approach, but you’ll have to read about part two to see why.


// More special utilities!
import dev.ericburden.aoc2023.Utils.repeating

/**
 * This enum represents a direction, either left or right.
 */
enum class Direction {
    LEFT,
    RIGHT;

    companion object {
        fun fromChar(char: Char): Direction {
            return when (char) {
                'L' -> LEFT
                'R' -> RIGHT
                else -> throw IllegalArgumentException("$char cannot be parsed to a Direction!")
            }
        }
    }
}

/**
 * This class represents a "node" on the map.
 *
 * Each node essentially serves as a signpost to the next node,
 * identifying the name of either the next node to the left or
 * the next node to the right.
 *
 * @property left The name of the next node to the left.
 * @property right The name of the next node to the right.
 */
data class Signpost(val left: String, val right: String) {
    fun nextFromDirection(direction: Direction): String {
        return when (direction) {
            Direction.LEFT -> left
            Direction.RIGHT -> right
        }
    }
}

/**
 * This class represents an instance of our mysterious map.
 *
 * @property directions A private iterator that can continually
 * produce the next [Direction] to take.
 * @property map The mapping of "node" name to the signpost for
 * the next possible nodes.
 */
class NodeMap(private val directions: Iterator<Direction>, val map: Map<String, Signpost>) {
    companion object {
        /**
         * Parses a [NodeMap] from the input file chunks.
         *
         * @param input A list of "chunks" of the input file, where
         * each "chunk" is a list of lines.
         */
        fun fromInput(input: List<List<String>>): NodeMap {
            val (directionChunk, nodeChunk) = input
            val directions = directionChunk.single().map(Direction::fromChar).repeating()

            // '.associate' is analagous to 'map().toMap().'
            val map = nodeChunk.associate { line ->
                val re = """(\w+) = \((\w+), (\w+)\)""".toRegex()
                val matchResult =
                    re.find(line)
                        ?: throw IllegalArgumentException(
                            "$line is not formatted properly!"
                        )
                val (label, left, right) = matchResult.destructured
                label to Signpost(left, right)
            }

            return NodeMap(directions, map)
        }
    }
}

class Day08(input: List<List<String>>) {

    // Parse that input!
    private val nodeMap = NodeMap.fromInput(input)
    
}

Today, I learned how to do one of my favorite things (implementing an iterator) in Kotlin. Yay! I’ve added it to my utilities package, since it seems like it will be handy to have a way to make a list loop over and over. Here’s what the implementation for that looks like:


/**
 * Return an iterator that outputs the contents of the list infinitely.
 *
 * This function extends the functionality of a [List<T>] by adding
 * a 'repeating` function that returns an iterator that returns the
 * values of the list, in order, starting over when the list is
 * exhausted.
 *
 * @return A RepeatingList over the list.
 */
fun<T> List<T>.repeating(): Iterator<T> = RepeatingList(this)

/**
 * This class represents an iterator that repeats the values in a list.
 *
 * @property list The list to repeat.
 */
class RepeatingList<T>(private val list: List<T>) : Iterator<T> {
    private var currentIndex = 0

    override fun hasNext(): Boolean {
        return list.isNotEmpty()
    }

    override fun next(): T {
        if (list.isEmpty()) {
            throw NoSuchElementException("List is empty")
        }

        val element = list[currentIndex]
        currentIndex = (currentIndex + 1) % list.size
        return element
    }
}

It may not be the most elegant way to handle this, but I like it!

Part One - That Rude Sandstorm

The elf was a ghost! And she left us in the path of a sandstorm! At least we have a map. Hopefully it’s a map to safety, although that isn’t really specified. If nothing else, it’s a bit of a network problem to work on while the storm rolls in… In true Advent of Code fashion, our goal is to find the shortest path through a ~graph~ desert.


class NodeMap(private val directions: Iterator<Direction>, val map: Map<String, Signpost>) {
    // companion object { ... }

    /**
     * Advance from a position to some other position that satisfies a condition.
     *
     * Given the name of a node on the map, follow the directions and advance from
     * node to node until the current node satisfies some condition.
     *
     * @param start The name of the node to start at.
     * @param stop A predicate function that indicates when to stop advancing.
     * @return A pair of the number of steps taken and the name of the node stopped on.
     */
    fun advanceUntil(start: String, stop: (String) -> Boolean): Pair<Int, String> {
        var currentLocation = start
        var steps = 0

        while (!stop(currentLocation)) {
            currentLocation = this.advanceOnce(currentLocation)
            steps += 1
        }

        return steps to currentLocation
    }
}

class Day08(input: List<List<String>>) {

    // private val nodeMap = ...

    // In part one, we follow the signs from our starting position
    // to our target and count the steps taken.
    fun solvePart1(): Int = nodeMap.advanceUntil("AAA") { it == "ZZZ" }.first
    
}

That wasn’t so bad! Who needed that spooky elf anyway?

Part Two - Splitting Headache

Wait. What? I can’t tell if we’re actually trying to ignore the laws of space-time and walk multiple simultaneous paths the way we assume the ghost can or if we’re just kind of curious how the ghost managed to get away so fast. If I’m being honest, I’d suspect it has more to do with being a ghost than with map traversal, but what do I know? In part two, we need to somehow start on all the nodes that end with ‘A’ and walk to all the nodes that end with ‘Z’ all our versions land on a ‘Z’-ending node simultaneously. Guess ghosts don’t know how to just stop and wait for the others to catch up. Oh, actually, that sort of makes sense…


class NodeMap(private val directions: Iterator<Direction>, val map: Map<String, Signpost>) {
    // companion object { ... }

    // fun advanceUntil(start: String, stop: (String) -> Boolean): Pair<Int, String> {
    //    ...
    // }
    
    /**
     * Advance one step from a given node.
     *
     * Given the name of a node on the map, follow the directions and advance
     * a single step forward.
     *
     * @param start The name of the node to start at.
     * @return The name of the next node in sequence.
     */
    fun advanceOnce(start: String): String {
        val direction = directions.next()
        val node = map[start] ?: throw IllegalArgumentException("$start is not a node on the map!")
        return node.nextFromDirection(direction)
    }
}

class Day08(input: List<List<String>>) {

    // private val nodeMap = ...

    // fun solvePart1(): Int = ...
    
    // In part two we pretend to be some sort of quantum ghost and
    // try to take multiple paths simultaneously. This seems like it
    // might be _more_ traumatic than the sandstorm...
    fun solvePart2(example: Boolean = false): Long {
        // Predicates to select lists that end with 'A' or 'Z'.
        val endsWithA: (String) -> Boolean = { str -> str[str.length - 1] == 'A' }
        val endsWithZ: (String) -> Boolean = { str -> str[str.length - 1] == 'Z' }

        // Our starting locations are the ones that end with 'A'
        val startingLocations = nodeMap.map.keys.filter(endsWithA)
        val destinations = startingLocations.map { loc -> nodeMap.advanceUntil(loc, endsWithZ) }

        // Need to check and be sure that each 'path' starting from a node whose
        // name ends with 'A' is actually cyclical. If it _does_ take the same
        // number of steps to get back to the _same_ end node as it took to get
        // there originally, then we can calculate the number of steps needed to
        // get to _all_ end nodes as the least common multiple of the number of
        // steps in each path in a cycle. If not... then my only other option
        // (that I know of) is to turn on the brute force method of just taking
        // one step on each path then checking to see if all paths found an end.
        // Oddly enough, this enters an endless loop on the part two example
        // (it's that "XXX = (XXX, XXX)" line), so I need to skip this bit when
        // running my test on the example input. _Kind_ of a bummer that the apparent
        // intended solution fails on the example.
        if (!example) {
            val nextDestinations = destinations.map { (_, loc) ->
                val start = nodeMap.advanceOnce(loc)
                val (steps, end) = nodeMap.advanceUntil(start, endsWithZ)
                steps + 1 to end// Account for that one extra step from the end
            }
            assert(destinations == nextDestinations) // Cross your fingers!
        }

        // I happen to know that this works, at least for my input.
        return destinations.map { it.first.toLong() }.lcm()
    }
}

Pro Tip: When you’re naive brute-force solution starts to make your computer fan kick on and run for more than thirty seconds, you’re missing something. Many times, that something is a cycle you can exploit in some way. In this case, it turns out that all the individual ‘__A’ -> ‘__Z’ paths were cyclical and it took the same number of steps to go from ‘__A’ to ‘__Z’ as it took to make another trip around starting from that same endpoint. With that discovery in place, the number of steps is as many as it takes for the periodicity of all the paths to line up.

Wrap Up

This was a good day! To be fair, I’m a wee bit miffed that the example input for part two breaks my code I used to check to see if the “one weird trick” for finding the total number of steps would work. That caused me a bit of a headache, I can tell you for free. On the other hand, I got to learn how to implement my own iterator, how to pass lambdas to functions (so that’s how you get that “curly-braces after the parentheses” syntax!), and how to extract regular expression matches from a string. All told, it was a very productive day for learning Kotlin, and that’s what I’m here for!

Advent of Code 2023 - Day 07

Thu, 07 Dec 2023 00:00:00 +0000

Day 7 - Camel Cards

Find the problem description HERE.

The Input - Dromedary Deck

Hmm, the input looks suspiciously straightforward to parse today. It’s an odd-numbered, day, though, so I’m still cautious about the difficulty level. Regardless, here we’ve got input in lines, each one containing two strings separated by a single space, where we need a list of characters from the first string and a parsed integer from the second. That’s do-able! I’ll also be representing each card as hand type as an enum with an associated ‘strength’ that can help us when sorting later.


/**
 * This enumeration represents the various types of Camel Cards
 *
 * @param strength The strength of the card when it comes to sorting.
 */
enum class CamelCard(val strength: Int) {
    ACE(14),
    KING(13),
    QUEEN(12),
    JACK(11),
    TEN(10),
    NINE(9),
    EIGHT(8),
    SEVEN(7),
    SIX(6),
    FIVE(5),
    FOUR(4),
    THREE(3),
    TWO(2),
    JOKER(1); // For Part Two

    companion object {
        /**
         * Parse a [CamelCard] from a [Char]
         *
         * @param char The Char value to parse.
         * @return The corresponding [Camel Card].
         */
        fun fromChar(char: Char): CamelCard {
            return when (char) {
                'A' -> ACE
                'K' -> KING
                'Q' -> QUEEN
                'J' -> JACK
                'T' -> TEN
                '9' -> NINE
                '8' -> EIGHT
                '7' -> SEVEN
                '6' -> SIX
                '5' -> FIVE
                '4' -> FOUR
                '3' -> THREE
                '2' -> TWO
                else -> throw IllegalArgumentException(
                  "$char does not represent a CamelCard!"
                )
            }
        }
    }
}

/**
 * This enumeration represents the various kinds of hands
 *
 * @param strength The strength of this kind of hand when it comes to sorting.
 */
enum class HandKind(val strength: Int) {
    FiveOfAKind(7_000_000),
    FourOfAKind(6_000_000),
    FullHouse(5_000_000),
    ThreeOfAKind(4_000_000),
    TwoPair(3_000_000),
    OnePair(2_000_000),
    HighCard(1_000_000);

    companion object {
        /**
         * Classify a hand of [CamelCard]s into a [HandKind]
         *
         * Check a list of camel cards for special cases, like four of a kind, 
         * and return the highest-strength classification possible for that 
         * list of cards. The classifications are the variants of [HandKind].
         *
         * @param cards The list of cards to be classified.
         * @return The [HandKind] representing the classification of the cards.
         */
        fun classify(cards: List<CamelCard>): HandKind {
            var counts = MutableList(15) { 0 }
            cards.forEach { card -> counts[card.strength] += 1 }

            val maxCount = counts.max()
            val pairCount = counts.filter { it == 2 }.count()
            return when (maxCount) {
                5 -> FiveOfAKind
                4 -> FourOfAKind
                3 -> if (pairCount > 0) FullHouse else ThreeOfAKind
                2 -> if (pairCount == 2) TwoPair else OnePair
                else -> HighCard
            }
        }
    }
}

/**
 * This class represents a hand of [CamelCard]s
 *
 * Each hand contains five cards, and the strength of that hand can be derived 
 * from the identity and order of those cards. Each hand also includes the 
 * accompanying bid, used to calculate the final result for both parts of 
 * today's puzzle.
 *
 * @param cards The list of [CamelCard]s in hand.
 * @param bid The value of the bid.
 * @param kind The [HandKind] classification of the hand.
 * @param strength The strength of this hand when it comes to sorting.
 */
data class CamelCardHand
private constructor(val cards: List<CamelCard>, val bid: Int, val kind: HandKind) {
    companion object {
        /**
         * Parse a [CamelCardHand] from a line of the input string.
         *
         * Each line includes the cards (as a string where each character
         * represents a card) and a  bid.
         *
         * @param string The input line to be parsed.
         * @return A hand of Camel Cards.
         */
        fun fromString(string: String): CamelCardHand {
            val (cardString, bidString) = string.split(" ")
            require(cardString.length == 5) {
                throw IllegalArgumentException("A hand must contain five cards!")
            }
            val cards = cardString.map { CamelCard.fromChar(it) }
            val bid = bidString.toInt()
            val kind = HandKind.classify(cards)
            return CamelCardHand(cards, bid, kind)
        }
    }
}

class Day07(input: List<String>) {

    // With the data nicely modeled, parsing is a breeze!
    private val parsed = input
      .filter { it.isNotEmpty() }
      .map { CamelCardHand.fromString(it) }

}

That’s still a fair bit of code, but the enums tend to make it look like more than it is. This should set us up nicely for part one.

Part One - A Link in the Chain

I’ve figured it out! We’re in a Zelda game. “Fetch me that sword!” “You can have my sword, but before I give it to you, fetch me a sandwich!” “I’d love to make you a sandwich, but this bug in my house is driving me mad. What, you don’t have a bug net? Maybe the raccoon in the woods has one.” That’s what we’re doing here. I’m going to be both extremely amused and a bit exasperated if those jokers on the ground with the trebuchet have the last piece of this quest chain… Ah well, at least we get to play a lovely game of poker while traveling via camel. That actually sounds kind of fun! Let’s sort out these hands of cards!


// I made my own!
import dev.ericburden.aoc2023.Utils.pow

// enum class CamelCard(val strength: Int) { ... }

// enum class HandKind(val strength: Int) { ... }

data class CamelCardHand
private constructor(val cards: List<CamelCard>, val bid: Int, val kind: HandKind) {
    companion object { ... }
    
    /**
     * Calculate and return the total strength of this hand.
     * 
     * The strength of a hand is derived from the individual cards in it, their 
     * order, and what kind of hand is formed by those cards. Each card in the 
     * hand is worth it's own strength times its place value. The place value is 
     * 14 (the maximum card strength) raised to the place index (descending from 
     * left to right). For example, the cards [2, 2, 2, 2, 2] would have place 
     * values of [2 * 14^4, 2 * 14^3, 2 * 14^2, 2 * 14^1, 2 * 14^0]. The strength 
     * derived from the _kind_ of hand is the most influential, since hands are 
     * sorted based on kind, then on the order of the cards. For this reason, 
     * each kind contributes an extra 1_000_000 to the strength, which is 
     * greater than the maximum possible strength derived from any set of cards 
     * ([A, A, A, A, A] = 579,194), and they're nice round numbers! These values 
     * contribute to a strength score such that, when sorted by that strength, 
     * hands will be sorted first on the kind of hand then on the order of the
     * individual cards.
     * 
     * @return The total strength of this hand.
     */
    val strength: Int
        get() {
            val maxCardIdx = cards.size - 1
            val cardStrength =
                    cards.zip(maxCardIdx downTo 0).sumOf { (card, exp) ->
                        card.strength * 14.pow(exp)
                    }
            return cardStrength + kind.strength
        }
}

class Day07(input: List<String>) {

    // private val parsed = ...

    // The trickiest bit to part one was telling the difference between a hand with
    // on pair and a hand with two pair.
    fun solvePart1(): Int =
            parsed
              .sortedBy { it.strength }
              .withIndex()
              .sumOf { (idx, hand) -> (idx + 1) * hand.bid }

}

There we go! A bit of math to make sure that all the hands are scored and sorted correctly. I do feel a bit clever basically treating the different types of cards as a base-14 number and converting it to decimal. Snaps for me! I also decided to stop complaining about the lack of an exponentiation function for integers and just make my own. So there!

Part Two - Speaking of Jokers…

Now this game is about to get wild! (Yes, I did that. I’m not ashamed.) Looks like all the Jacks were really Jokers which can pretend to be anything else! While at first this seems like a major twist, it ends up being not too tricky to handle.


// enum class CamelCard(val strength: Int) { ... }


enum class HandKind(val strength: Int) {
    FiveOfAKind(7_000_000),
    FourOfAKind(6_000_000),
    FullHouse(5_000_000),
    ThreeOfAKind(4_000_000),
    TwoPair(3_000_000),
    OnePair(2_000_000),
    HighCard(1_000_000);

    companion object {
    
        // fun classify(cards: List<CamelCard>): HandKind { ... }

        /**
         * Classify a hand of cards containing Jokers
         *
         * This could have been included in the `HandKind.classify` function, 
         * but I separated it out  because it's only used in part 2. For hands 
         * that contain Jokers (and treat them as wildcards), we determine what 
         * the hand _would be_ without the jokers, then promote the 
         * classification one step for each Joker found.
         *
         * @param cards A list of cards where Joker are wild.
         * @return The [HandKind] representing the classification of the cards.
         */
        fun classifyWithJokers(cards: List<CamelCard>): HandKind {
            // What kind of hand would it be without the Jokers?
            var handKind = classify(cards.filter { it != CamelCard.JOKER })

            // For every Joker in the hand, increase the value of the hand by 
            // one step, always choosing the next possible kind with the highest
            // strength possible.
            val jokerCount = cards.filter { it == CamelCard.JOKER }.count()
            repeat(jokerCount) {
                handKind =
                        when (handKind) {
                            FiveOfAKind -> FiveOfAKind // Best we can do
                            FourOfAKind -> FiveOfAKind
                            FullHouse -> FourOfAKind
                            ThreeOfAKind -> FourOfAKind
                            TwoPair -> FullHouse
                            OnePair -> ThreeOfAKind
                            HighCard -> OnePair
                        }
            }

            return handKind
        }
    }
}

data class CamelCardHand
private constructor(val cards: List<CamelCard>, val bid: Int, val kind: HandKind) {
    // companion object { ... }

    // val strength: Int get() { ... }

    /**
     * Replace all the Jacks in a hand with Jokers
     * 
     * Recalculates the [HandKind] of this hand with Jokers included.
     * 
     * @return A copy of this hand with all Jacks replaced with Jokers.
     */
    fun replaceJacksWithJokers(): CamelCardHand {
        val cards = cards.map { if (it == CamelCard.JACK) CamelCard.JOKER else it }
        val kind = HandKind.classifyWithJokers(cards)
        return CamelCardHand(cards, bid, kind)
    }
}

class Day07(input: List<String>) {

    // private val parsed = ...

    // fun solvePart1(): Int = ...

    // The trickiest bit to part two was that one hand with all Jacks!
    fun solvePart2(): Int =
            parsed
              .map { it.replaceJacksWithJokers() }
              .sortedBy { it.strength }
              .withIndex()
              .sumOf { (idx, hand) -> (idx + 1) * hand.bid }
}

The “one weird trick” here is realizing you don’t need to actually know what card the Jokers are pretending to be, you just need to know what effect they have on the hand. And that effect is to make it one stage better than it was!

Wrap Up

Now, this was a fun puzzle! I got to explore some Kotlin features I hadn’t touched yet (enum and importing my own extension function from a ‘Utils.kt` module), do a bit of math, and generally have a good time! I think I needed that. Here’s to hoping I’m not being lulled into a false sense of security.

Advent of Code 2023 - Day 06

Wed, 06 Dec 2023 00:00:00 +0000

Day 6 - Wait For It

Find the problem description HERE.

The Input - Hold, Hold, Hold Your Boat

Today’s input is really short. Two lines, with whitespace-separated numbers being all we care about. I did try to be a bit fancy with it, but it’s still very straightforward. I did make use of the ability to assign an anonymous function to a variable, which is new for me in Kotlin. A welcome break from yesterday!

/**
 * Class that represents one of the current distance records
 *
 * Each race can be represented as the time limit and the last record distance.
 *
 * @property time The time available to complete the race.
 * @property distance The last record distance (we need to beat).
 */
data class RaceRecord(val time: Double, val distance: Double) {
    companion object {
        /**
         * Parse the input from a string representing the input file
         *
         * Today's input is only two lines and they both mean different things, so we'll parse the
         * input as a single string, convert each line to a list of numbers, and zip them together
         * to make our [RaceRecord]s
         */
        fun parseInput(input: String): List<RaceRecord> {
            val toDoubleOrThrow: (String) -> Double = { n ->
                n.toDoubleOrNull()
                        ?: throw IllegalArgumentException("$n cannot be parsed to a Double!")
            }

            val (raceTimes, raceDistances) =
                    input.trim().split("\\n".toRegex()).map { line ->
                        line.replaceFirst("\\w+:".toRegex(), "")
                                .trim()
                                .split("\\s+".toRegex())
                                .map(toDoubleOrThrow)
                    }

            return raceTimes.zip(raceDistances) { time, distance -> RaceRecord(time, distance) }
        }
    }
}

class Day06(input: String) {

    // One string to one list. Piece of cake.
    private val parsed = RaceRecord.parseInput(input)

}

We’ve seen a pattern of alternating difficulty levels on puzzles so far this year, and today seems to be no exception.

Part One - We’re Going Quadratic!

Do you ever get that feeling when you’re reading a problem statement that there’s probably some easy way to solve it if you just used math? Sometimes I get that feeling, and it really grinds my gears because I can’t figure out what the math is. And sometimes, the math reveals itself. Today, the math came through! Here in part one, we need to figure out how many ways we can win a boat race based on how long we need to charge up the boat.


// My first imports!
import kotlin.math.ceil
import kotlin.math.floor
import kotlin.math.sqrt

data class RaceRecord(val time: Double, val distance: Double) {
    // companion object { ... }

    /**
     * Return the number of different ways we can win the race!
     *
     * @ return An Int indicating just how many different hold times will get us
     * the winning distance.
     */
    fun countWinningStrategies(): Int {
        // For: Hold Time -> h; Race Time -> t; Distance to Beat -> d
        // We can derive a formula for beating the previous record as:
        //   - (t - h) * h > d
        //
        // Which rearranges to: (-1)*h^2 + (t * h) - d > 0
        // Now, that there is a quadratic expression! You know, the old
        // `ax^2 + bx + c = 0`? We can solve it like:
        //     h = (-t +/- sqrt(t^2 - 4 * (-1) * (-d))) / 2 * (-1)
        //
        // That's math! The 'tricky' part is that we don't want to know the _exact_
        // hold time to _equal_ the previous record, we want to know the smallest
        // and largest hold times that will _beat_ the record. For that, we round
        // _away_ from the mean possible hold time and then adjust our value towards
        // the mean by 1. For example, the results of this formula for the first
        // example race (7ms, 9mm) indicate that you could travel the 9mm by holding
        // the button for 1.697ms or 5.303ms. The minimum number of whole milliseconds,
        // then is `floor(1.697) + 1` and the maximum is `ceil(5.303) - 1`. This
        // correctly handles cases where the exact time is an integer as well.
        val sqrtFormulaPart = sqrt((time * time) - (4 * distance))
        val minWinningHold = floor((-time + sqrtFormulaPart) / -2).toInt() + 1
        val maxWinningHold = ceil((-time - sqrtFormulaPart) / -2).toInt() - 1

        // The total number of winning holds is the length of the inclusive range
        // of all possible winning holds.
        return (maxWinningHold - minWinningHold) + 1
    }
}

class Day06(input: String) {

    // One string to one list. Piece of cake.
    // private val parsed = ...

    // In part 1, we calculate all our winning hold times and return
    // the product of that count from each race.
    fun solvePart1(): Int = parsed
      .map { it.countWinningStrategies() }
      .reduce { acc, n -> acc * n }

}

Yay, math!

Part Two - Kerning for Dummies

You know, one of these days, we’re going to stop and take a second look at an input before we start writing code. Of course, that would take half the fun out of solving these puzzles, so there’s that. Turns out, there’s only one race, so we just need to figure out how many ways we can win that one.


data class RaceRecord(val time: Double, val distance: Double) {
    // companion object { ... }

    // fun countWinningStrategies(): Int { ... }
}

class Day06(input: String) {

    // One string to one list. Piece of cake.
    // private val parsed = ...

    // In part 1, we calculate all our winning hold times and return
    // the product of that count from each race.
    // fun solvePart1(): Int = ...

    // In part 2, we learn what 'kerning' is and get mad about it. Then
    // we concatenate all the race times/records into one and figure how
    // how many ways we can win that one race.
    fun solvePart2(): Int {
        val uberRaceTime = parsed
          .joinToString("") { it.time.toInt().toString() }
          .toDouble()
        val uberDistance = parsed
          .joinToString("") { it.distance.toInt().toString() }
          .toDouble()
        return RaceRecord(uberRaceTime, uberDistance).countWinningStrategies()
    }
}

Yep, the same math works for part 2!

Wrap Up

Well, well, well, here we are again with a lighter day. I don’t have too much to say about today’s puzzle, probably because I’m still recovering from yesterday. I do appreciate the opportunity to get caught back up, though, which is nice. Let’s all enjoy this lighter day, and get ready for the fresh trial that the next odd-numbered day is likely to bring!

Advent of Code 2023 - Day 05

Tue, 05 Dec 2023 00:00:00 +0000

Day 5 - If You Give A Seed A Fertilizer

Find the problem description HERE.

The Input - It’s Honest Work

“Advent of Parsing” indeed! This was the first day I got to break out my resourceAsLineChunks() file reading function, though, which is pretty cool. As you might have guessed, today’s input takes a hefty amount of parsing to get it into shape. The heavy lifting is the Map used to trace one resource number/range to another, and it is a bit gnarly.


// This is a bit of a complicated type. Essentially, we are representing one
// translation from one resource type to another. For example, to the mapping of
// the 'seed-to-soil' group from the example:
//
//     seed-to-soil map:
//     50 98 2
//     52 50 48
//
// is represented as ("seed", ("soil", [(98..99, -48), (50..97, 2)])). This makes
// it a bit easier to use in the code below, as the list of them can be easily
// converted to a HashMap.
typealias ResourceRangeTranslationGroup = 
  Pair<String, Pair<String, List<Pair<LongRange, Long>>>>

/**
 * This class represents the contents of the elf's Almanac
 *
 * @property seeds A list of the seed numbers in ("seed", <seed number>) format.
 * @property mappings A map used to determine what type of resource is required.
 */
data class Almanac(
    val seeds: List<Pair<String, Long>>,
    val mappings: Map<String, Pair<String, List<Pair<LongRange, Long>>>>
) {
  companion object {
    /**
     * Parse the input from a list of input chunks.
     *
     * @param chunks A list of line chunks from the input.
     * @return The parsed Almanac.
     */
    fun fromInputChunks(chunks: List<List<String>>): Almanac {
      // This bit isn't too bad. We parse the first line into  a list of
      // ("seed", <number>) pairs. This is so, when we attempt to go from one
      // resource to another later on, we've tagged this number with the type
      // of resource it represents.
      val seeds =
          chunks
          .first()
          .first()
          .removePrefix("seeds: ")
          .split("\\s+".toRegex()).map {
            val seedNumber =
                it.toLongOrNull() ?: 
                  throw IllegalArgumentException("$it cannot be parsed to Long!")
            "seed" to seedNumber
          }

      // Parsing the "x-to-y map" chunks was a bit involved, so I've moved
      // that logic to its own function.
      val mappings = chunks
        .drop(1)
        .filter { it.isNotEmpty() }
        .map { parseChunk(it) }
        .toMap()

      return Almanac(seeds, mappings)
    }

    /**
     * Parse one chunk of the input file
     *
     * This is where we're using the gnarly type alias defined at the top. The 
     * idea is to produce a list that can be converted to a Map that can be used 
     * to look up, for each resource, what numbers for the next resource it needs.
     *
     * @param lines The input lines for one chunk of the input file.
     * @return An object that can become an entry in the [Almanac.mappings] map.
     */
    fun parseChunk(lines: List<String>): ResourceRangeTranslationGroup {
      // Get which resource types we're dealing with.
      val (sourceType, targetType) = lines.first().removeSuffix(" map:").split("-to-")

      // For each subsequent line in the chunk, we extract two pieces of information:
      // 1. The range of the source resource
      // 2. The magnitude of the offset of the destination resource range from 
      //    the source range. This works because the source range and destination 
      //    ranges are constrained to be the same size by the input.
      val rangeMappings =
          lines
              .filter { it.isNotEmpty() }
              .drop(1)
              .map { line ->
                val (destinationRangeStart, sourceRangeStart, rangeLength) =
                    line.split("\\s+".toRegex()).map {
                      // Yes, I'm being paranoid.
                      it.toLongOrNull()
                          ?: throw IllegalArgumentException("$it cannot be parsed to Long!")
                    }
                val sourceRange = sourceRangeStart until (sourceRangeStart + rangeLength)
                val rangeShift = destinationRangeStart - sourceRangeStart
                sourceRange to rangeShift // Pair<LongRange, Long>
              }
              .sortedBy { it.first.start }
      return sourceType to (targetType to rangeMappings)
    }
  }
}


class Day05(input: List<List<String>>) {

  // And this was the easy part...
  private val parsed = Almanac.fromInputChunks(input)
  
}

Yes, I’m serious. That was the easy part. Well, in hindsight, now that I know all the edge cases and little mistakes, it’s not that bad. Still, though, get ready for round 1.

Part One - Agricultural Delivery

You know what? It’s kind of rare that we see an elf suffering the inevitable consequences of someone else’s poor design decisions. I kind of feel sorry for this guy. How is anyone supposed to map out the instructions included in this almanac? Also, who numbers seeds? Seems like a system designed to fail. Maybe the almanac sellers run a paid support plan… Well, we’re here now. Time to figure out where these seeds go.

data class Almanac(
    val seeds: List<Pair<String, Long>>,
    val mappings: Map<String, Pair<String, List<Pair<LongRange, Long>>>>
) {

  // companion object { ... }
  
  /**
   * Given a resource, traces it's requirements all the way to a location
   *
   * This is why I'm tagging the resource numbers like ("seed", 1). So I can 
   * pass that pair to this function and have it recursively search through the 
   * [Almanac] until the corresponding location is found.
   *
   * @param resource A pair of ("resource type", <number>) to find the location for.
   * @return A pair of ("location", <location number>)
   */
  fun resourceToLocation(resource: Pair<String, Long>): Pair<String, Long> {
    val (type, id) = resource
    if (type == "location") return resource

    // Get the mappings of source type ranges to destination type ranges
    val (destinationType, possibleDestinations) =
        mappings.get(type)
            ?: throw IllegalArgumentException("Could not find a destination for $type.")

    // If there is a matching mapping, then map the source number to the
    // destination number and return it.
    try {
      val destination =
          possibleDestinations
              .filter { (range, _) -> id in range }
              .map { (_, offset) -> id + offset }
              .single()
      return this.resourceToLocation(destinationType to destination)
    } catch (e: Exception) {
      // If there is no mapping, then we know that the destination number
      // is the same as the source number.
      return this.resourceToLocation(destinationType to id)
    }
  }
}

class Day05(input: List<List<String>>) {

  // Told you this was the easy part.
  // private val parsed = ...

  // In part one, we have a few seeds to follow all the way to their
  // ideal planting locations. Easy enough.
  fun solvePart1(): Long =
      parsed.seeds.map { parsed.resourceToLocation(it) }.minOf { (_, id) -> id }

Ok, fine, that wasn’t too bad. But wait, there’s more!

Part Two - Sow, Sow Many

I seriously doubt the elf has access to the literal billions of unique seeds indicated by this almanac. Not to mention all those unique locations! How big is this island, anyway. Not that big, that’s for sure. In part two, it seems we’ve once again misinterpreted plain text and the seed “numbers” are seed number “ranges”. We still need to find the closest location (which kind of makes sense, some of these are probably in outer space), though, but individually tracing each seed to its location isn’t going to cut it.

data class Almanac(
    val seeds: List<Pair<String, Long>>,
    val mappings: Map<String, Pair<String, List<Pair<LongRange, Long>>>>
) {

  // companion object { ... }
  
  // fun resourceToLocation(resource: Pair<String, Long>): Pair<String, Long> { ... }
  
  /**
   * Given a range of resource numbers, return all the possible location ranges
   *
   * In Part 2, the numbers are just too big for us to map each seed to its 
   * location individually. Instead, we need to map the resources by the entire 
   * range. The catch here is that the input range won't always slot neatly 
   * inside an output range and may instead encompass several ranges.
   * For that reason, we return a list of ("resource type", <range>) pairs.
   *
   * @param resourceRange A pair of ("resource type", <range>) to find location 
   *                      ranges for.
   * @return A list of all the location ranges the input range maps to.
   */
  fun resourceRangeToLocationRanges(
      resourceRange: Pair<String, LongRange>
  ): List<Pair<String, LongRange>> {
    val (type, sourceRange) = resourceRange
    if (type == "location") return listOf(resourceRange) // Base case

    val (destinationType, possibleDestinations) =
        mappings.get(type)
            ?: throw IllegalArgumentException("Could not find a destination for $type.")
    // Still paranoid

    // This will house all the destination ranges we find.
    var destinationRanges = mutableListOf<LongRange>()

    // If the `sourceRange` starts before the first `possibleDestinationRange`, 
    // then we need to add that non-overlapping part to the destinations as-is
    val (firstPossibleDestinationRange, _) = possibleDestinations.first()
    if (sourceRange.start < firstPossibleDestinationRange.start) {
      val prefixRangeEnd = minOf(
        sourceRange.endInclusive + 1, 
        firstPossibleDestinationRange.start
      )
      val prefixRange = sourceRange.start until prefixRangeEnd
      destinationRanges.add(prefixRange)
    }

    // Now, check over all the `possibleDestinations` and, for every destinationRange
    // that overlaps `range`, apply the offset to the overlapping portion of `range`
    // and add it to the destinations
    for ((destinationRange, destinationOffset) in
        possibleDestinations.sortedBy { it.first.start }) {
      if (sourceRange.start <= destinationRange.endInclusive &&
              destinationRange.start <= sourceRange.endInclusive
      ) {
        val overlappingRangeStart = maxOf(sourceRange.start, destinationRange.start)
        val overlappingRangeEnd = minOf(
          sourceRange.endInclusive, 
          destinationRange.endInclusive
        ) + 1
        val overlappingRange =
            (overlappingRangeStart + destinationOffset) until
                (overlappingRangeEnd + destinationOffset)
        destinationRanges.add(overlappingRange)
      }
    }

    // Finally, if `sourceRange` extends past the end of the last `destinationRange`,
    // then we need to add that non-overlapping part to the destinations as-is.
    var (lastPossibleDestinationRange, _) = possibleDestinations.last()
    if (sourceRange.endInclusive > lastPossibleDestinationRange.endInclusive) {
      val suffixRangeStart = maxOf(
        sourceRange.start, 
        lastPossibleDestinationRange.endInclusive + 1
      )
      val suffixRange = suffixRangeStart until sourceRange.endInclusive + 1
      destinationRanges.add(suffixRange)
    }

    // Now with our list of destination ranges, we need to recursively search
    // for the ranges of the final locations.
    return destinationRanges
        .map { this.resourceRangeToLocationRanges(destinationType to it) }
        .flatten()
  }
}

class Day05(input: List<List<String>>) {

  // Told you this was the easy part.
  // private val parsed = ...

  // How you like me now?
  // fun solvePart1(): Long = ...
  
  // In part two, we have a _tremendous_ number of seeds to track down.
  // Instead, we need to keep track of ranges of numbers to finish in a
  // reasonable amount of time.
  fun solvePart2(): Long {
    // Convert the seed numbers to ranges as specified in the puzzle text.
    val seedRanges =
        parsed.seeds.chunked(2) { (first, second) ->
          val (_, rangeStart) = first
          val (_, rangeLength) = second
          "seed" to (rangeStart until (rangeStart + rangeLength))
        }

    // For all the possible location ranges, find the smallest possible location.
    return seedRanges
        .map { seedRange -> parsed.resourceRangeToLocationRanges(seedRange) }
        .flatten()
        .minOf { (_, range) -> range.start }
  }
}

Yes, of course I tried searching the seeds one at a time. What do you take me for? No, it didn’t work. I exceeded the JVM’s memory allocation. I could have probably worked around that, but the algorithm change seemed like the right idea.

Wrap Up

That was Day 5!? I checked, and last year Day 5 was the crate-moving day. And yes, while that did require a bit of tricky parsing (assuming you didn’t just hard-code the input), the algorithm bit was simplicity itself. And that took me around 260 lines of Rust code (which is heckin’ verbose) compared to today’s 222 lines of Kotlin code. That probably doesn’t seem like a bad comparison, but you have to remember that Rust tends to have a lot (relatively) of boilerplate. Strip all the comments, and it might even be less Rust code. Typically, by this point, I’d expect either a bit of a tougher parse or a bit of a trickier algorithm, but today was a double whammy. Now, I’m not complaining, mind you, I enjoy a good challenge. Given how the last few days have gone, though, I’m starting to get a bit concerned for my sleep schedule! We’ll see what Day 6 has in store.

Advent of Code 2023 - Day 04

Mon, 04 Dec 2023 00:00:00 +0000

Day 4 - Scratchcards

Find the problem description HERE.

The Input - Scratching the Itch

Today’s elf friend seems to have a bit of a problem… Which is that his “friends” decided that a big pile of scratchcards would make an appropriate gift. I’m not judging, but it looks like it’s put our elf friend to a lot of effort for dubious reward. Regardless, our first job is to translate this text into something representing these scratchers, so here we go!

/**
 * This class represents one of the elve's scratchcards
 *
 * @property id The id number assigned to this card.
 * @property luckyNumbers The winning scratchard numbers.
 * @property myNumbers The numbers revealed for the elf.
 */
data class Card private constructor(val id: Int, val matches: Int) {
  companion object {
    /**
     * Parses a [Card] from a String
     *
     * @param input The string to be parsed.
     * @return A [Card] represented by the input.
     */
    fun fromString(input: String): Card {
      // Split a string like "Card 1: 1 2 | 2 3 4" into ["Card 1", "1 2", "2 3 4"]
      val parts = input.split("[:|]".toRegex()).map { it.trim() }
      require(parts.size == 3) { "$input cannot be parsed to a [Card]!" }

      val (cardPart, luckyNumbersPart, myNumbersPart) = parts

      // Remove the "Card   " prefix. Note, the example only included one space
      // after "Card", but the real input included multiple for formatting.
      val id =
          cardPart.replaceFirst("Card\\s+".toRegex(), "").toIntOrNull()
              ?: throw IllegalArgumentException("$cardPart cannot be parsed to a card id!")

      // Parse lists of space-separated numeric strings into integers.
      val luckyNumbers =
          luckyNumbersPart.split("\\s+".toRegex()).map {
            it.toIntOrNull() ?: throw IllegalArgumentException("$it is not a number!")
          }
      val myNumbers =
          myNumbersPart.split("\\s+".toRegex()).map {
            it.toIntOrNull() ?: throw IllegalArgumentException("$it is not a number!")
          }

      // Turns out, we don't care about the numbers at all. Just count how many
      // of 'myNumbers' are in `luckyNumbers' and keep track of that.`
      val matches = myNumbers.filter { luckyNumbers.contains(it) }.count()

      return Card(id, matches)
    }
  }
}

class Day04(input: List<String>) {

  // Except for the trailing empty line, parse all the lines from
  // the input into [Card]s.
  private val parsed = input.filter { it.isNotEmpty() }.map(Card::fromString)
}

In my original iteration, I kept the lists of numbers as well. Since it turned out we didn’t really need to keep them around, I’ve left them out of this final version.

Part One - Counting Card’s Value

Ok, looks like the reward for all these scratchcards are “points” of unspecified value. On a value-scaling basis, they’re probably worth about as much as likes or upvotes, I figure. Given how precious these points are, we want to make sure we tally them correctly! Each card is worth a number of points based on how many of the revealed numbers match the winning numbers displayed on the card. Let’s see how rich this elf is!

data class Card private constructor(val id: Int, val matches: Int) {
  
  // companion object { ... }
  
  /**
   * Calculate the score for this card
   *
   * The score is 1 for a single match, doubled for every subsequent match. Mathematically, this
   * works out to 2 ** (matches - 1) for one or more matches.
   *
   * @return The calculated score for this card
   */
  fun score(): Int {
    // Apparently, Kotlin doesn't have a "nice" way to exponentiate integers
    // without first casting it to a double. I don't _want_ to do type
    // conversion for exponents! So, I'm just doubling the value in a loop.
    var score = if (matches == 0) 0 else 1
    if (matches > 1) {
      repeat(matches - 1) { score = score * 2 }
    }

    return score
  }
}

class Day04(input: List<String>) {

  // private val parsed = ...

  // In Part 1, we score each card and return the sum of all the scores.
  fun solvePart1(): Int = parsed.sumOf { it.score() }
}

Now that we’ve counted the elf’s vast wealth (in points), we should probably figure out how to spend them!

Part Two - The House Always Wins

Ah, I see, seems like we should have looked more closely at these cards. Turns out, our elf friend’s fabulous prize is… more scratchcards! Not sure how this translates, but at least he should have plenty of kindling or paper mâché materials. Elves are pretty crafty, so I’m sure he’s excited to find out just how many of these cards he’s entitled to. Let’s help him out.

class Day04(input: List<String>) {

  // private val parsed = ...

  // fun solvePart1(): Int = ...

  // In Part 2, we re-learn that reading is key and calculate the number
  // of cards our elf friend ends up with.
  fun solvePart2(): Int {
    // Each winning card increases the number of copies of subsequent cards
    // by one. The number of matches on the winning card indicates how many
    // of the following cards we "win" new copies of. So, a card with four
    // matches gets us one extra copy of the next four cards. We start
    // by initializing a list of card counts. Since cards are 1-indexed,
    // we make a list a little bigger than we need and just zero the first
    // value (no "Card 0").
    val cardsCounted = MutableList(parsed.size + 1) { 1 }
    cardsCounted[0] = 0

    // Here, we increase subsequent cards by the number of existing cards,
    // so that 10 copies of a winning card with three matches will add ten
    // more copies to each of the following three card types.
    parsed.forEach { card ->
      for (i in 1..card.matches) {
        cardsCounted[card.id + i] += cardsCounted[card.id]
      }
    }

    return cardsCounted.sum()
  }
}

Gotta be honest, I think I’d prefer to have the points!

Wrap Up

I was starting to get a bit worried after the relatively involved parsing of yesterday’s input, but it seems like we’re back on track in terms of relative difficulty for where we are in the calendar. I feel like I’m starting to get a handle on some of the standard library stuff, although the need to call .toRegex() on my strings in order to split the input by regular expressions threw me for a bit of a loop. Other than that, though, today’s puzzle seemed really straightforward. Oh, also, no integer exponentiation? Really? That seems like a bit of an odd gap. Thankfully, it’s easy enough to roll your own. Probably the biggest ’efficiency’ was adding the won cards in batches instead of one at a time, so I felt pretty good about that.

Advent of Code 2023 - Day 03

Sun, 03 Dec 2023 00:00:00 +0000

Day 3 - Gear Ratios

Find the problem description HERE.

The Input - All The Horsepower

And, it looks like we’ve gone right back to “parsing is the puzzle” for today’s Advent of Code. Well, more or less. I suspect I could have shifted some of the workload out of the parsing phase, but I’m kind of a fan of trying to model the inputs in such a way as to make the operations more tractable. So, here’s a bunch of input parsing!

import kotlin.collections.mutableMapOf

// There are two possible items on the schematic, either a number that
// may span multiple grid spaces, or a non-numeric character called a
// 'symbol'. Each number needs to be uniquely identified, so we can have
// numbers with duplicate values in the schematic representation below.
sealed class SchematicItem {
  data class Number(val id: Int, val number: Int) : SchematicItem()
  data class Symbol(val char: Char) : SchematicItem()
}

// Convenience!
typealias Coordinate = Pair<Int, Int>

/**
 * This class represents the engine schematic
 *
 * @property map A mapping of coordinates to schematic items
 * @property numbers A list allowing for easy iteration over numeric schematic items
 * @property symbols A list allowing for easy iteration over symbol schematic items
 */
data class EngineSchematic
private constructor(
    val map: MutableMap<Coordinate, SchematicItem>,
    val numbers: List<Pair<SchematicItem.Number, List<Coordinate>>>,
    val symbols: List<Pair<SchematicItem.Symbol, Coordinate>>
) {
  companion object {
    /**
     * This factory function serves as the constructor
     *
     * Parses an [EngineSchematic] from the input string
     *
     * @param input The input string
     * @return An [EngineSchematic] represented by the input string
     */
    fun fromString(input: String): EngineSchematic {
      val map = mutableMapOf<Coordinate, SchematicItem>()
      val numbers = mutableListOf<Pair<SchematicItem.Number, List<Coordinate>>>()
      val symbols = mutableListOf<Pair<SchematicItem.Symbol, Coordinate>>()

      // Iterate over the lines with support for skipping forward when
      // a multi-digit number is encountered.
      for ((row, line) in input.trimEnd().split("\n").withIndex()) {
        var col = 0
        while (col < line.length) {
          when (line[col]) {
            '.' -> col += 1 // Skip periods
            in '0'..'9' -> {
              // If the current character is a numeric digit, parse the full 
              // number, add it to the [map], and skip ahead to the end of the
              // number string
              var buffer = StringBuilder()
              val first_col = col
              val id = (row * line.length) + col // The ID for this number
              while (col < line.length && line[col].isDigit()) {
                buffer.append(line[col])
                col += 1
              }

              // No need to check the string, we guaranteed it only contains digits
              val partNumber = SchematicItem.Number(id, buffer.toString().toInt())

              // We'll also keep a list of numbers and the coordinates 
              // associated with all the digits of that number.
              var numberCoords = mutableListOf<Coordinate>()
              for (digit_col in first_col until col) {
                val coordinate = Coordinate(row, digit_col)
                map.put(coordinate, partNumber)
                numberCoords.add(coordinate)
              }

              numbers.add(partNumber to numberCoords)
            }
            else -> {
              // Otherwise, we're dealing with a symbol. A symbol gets added to 
              // the map and to the list of symbols and their coordinates.
              val symbol = SchematicItem.Symbol(line[col])
              val coordinate = Coordinate(row, col)
              map.put(coordinate, symbol)
              symbols.add(symbol to coordinate)
              col += 1
            }
          }
        }
      }

      return EngineSchematic(map, numbers, symbols)
    }
  }
}


class Day03(input: String) {

  // The real work is done here
  private val schematic = EngineSchematic.fromString(input)

}

That’s kind of a lot of parsing for Day 3, but the gist of it is that we end up with a data structure that maps all the “filled” grid coordinates to either the number of symbol found there and contains lists of both the numbers and symbols associated with their coordinates for efficient iteration of either.

Part One - When is a Number not a Number?

When it’s apart! Ok, fine, that wasn’t a good joke. I couldn’t help myself. In part 1 of today’s puzzle (fine, I’ll stop), we are tasked with reviewing a gondola schematic and deciding which numbers are real-life part numbers and which ones we can safely ignore. The part numbers are all adjacent (counting diagonally) to “symbols” on the schematic which likely represent some sort of fancy widget or dongle or somesuch. Doesn’t matter to us, though, we’re all about those numbers!

data class EngineSchematic
private constructor(
    val map: MutableMap<Coordinate, SchematicItem>,
    val numbers: List<Pair<SchematicItem.Number, List<Coordinate>>>,
    val symbols: List<Pair<SchematicItem.Symbol, Coordinate>>
) {

  // companion_object { ... }
  
  /**
   * Extract the true part numbers from the schematic
   *
   * Just because there's a number in the schematic doesn't mean it's a 
   * _part_ number. Which is weird. A real part number is adjacent to a symbol. 
   * This function checks around each number for a symbol and returns all 
   * [SchematicItem.Number]s with an adjacent symbol.
   *
   * @return A list of [SchematicItem.Number] objects
   */
  fun partNumbers(): List<SchematicItem.Number> {
    val offsets = listOf(
      -1 to -1, -1 to  0, -1 to 1, 0 to -1, 
       0 to  1,  1 to -1,  1 to 0, 1 to  1
    )
    val partNumbers = mutableListOf<SchematicItem.Number>()

    // For each number/list of coordinates pair in the [numbers] list,
    // check all around the number for a symbol. Technically, we're
    // re-checking several indices for numbers with multiple digits.
    // It's possible to keep track of coordinates checked, but I'm not
    // convinced it's worth the extra effort.
    for ((number, coordinates) in numbers) {
      number@ for (coordinate in coordinates) {
        for (offset in offsets) {
          // Get the neighboring coordinate to check
          val row = coordinate.first + offset.first
          val col = coordinate.second + offset.second
          val checkAt = Coordinate(row, col)

          // If there's a value at that coordinate and that value is
          // a [SchematicItem.Symbol], then this number really is
          // a part number! Add it to our list and move on.
          val maybeSymbol = map.get(checkAt) as? SchematicItem.Symbol
          if (maybeSymbol != null) {
            partNumbers.add(number)
            break@number
          }
        }
      }
    }

    return partNumbers
  }
}


class Day03(input: String) {

  // The real work is done here
  private val schematic = EngineSchematic.fromString(input)

  // In part one, we figure out which numbers really represent parts
  // and return the sum of all of them.
  fun solvePart1(): Int = schematic.partNumbers().sumOf { it.number }

}

There we go, not too stressful. Just check around each number for a symbol, and if we find one then it’s a part number. The tricky bit is that each number may take up more than one space on the grid. It might also be adjacent to more than one symbol (a quick scan of my input doesn’t reveal any, but I’m too paranoid to trust that). So, we need to make sure we consider each digit of each number and include or reject it only once.

Part Two - That’s What Grinds My Gears

You know, I had a feeling that it would actually matter what those symbols meant eventually. Sure enough, any ‘*’ that’s adjacent to two (and only two) numbers is a gear, and we kind of need to know what those numbers are so we can calculate the gear ratio. Also, I’m pretty sure that’s not how most people use the term “gear ratio”, but what do I know?

data class EngineSchematic
private constructor(
    val map: MutableMap<Coordinate, SchematicItem>,
    val numbers: List<Pair<SchematicItem.Number, List<Coordinate>>>,
    val symbols: List<Pair<SchematicItem.Symbol, Coordinate>>
) {

  // companion_object { ... }
  
  // fun partNumbers(): List<SchematicItem.Number> { ... }
  
  /**
   * Calculate and return all gear ratios in the schematic
   *
   * Some symbols are gears. Each gear is associated with two numbers, and the 
   * 'gear ratio' is the product of those two numbers.
   *
   * @return A list of all gear ratios represeted on the schematic
   */
  fun gearRatios(): List<Int> {
    val offsets = listOf(
      -1 to -1, -1 to  0, -1 to 1, 0 to -1, 
       0 to  1,  1 to -1,  1 to 0, 1 to  1
    )
    val ratios = mutableListOf<Int>()

    // For each symbol/coordinate pair in the symbols list, check around that
    // symbol for exactly two numbers. If two numbers are found, add their
    // product to the gear ratio list.
    symbol@ for ((symbol, coordinate) in symbols) {
      if (symbol.char != '*') continue // skip it, not a gear

      // We _do_ need to keep track of which numbers we've already seen,
      // since each number can have multiple digits and the symbol may
      // be adjacent to more than one of them.
      var numbersSeen = mutableSetOf<Int>()
      var numbersAdded = 0
      var ratio = 1

      // Check all around the symbol...
      for (offset in offsets) {
        val row = coordinate.first + offset.first
        val col = coordinate.second + offset.second
        val checkAt = Coordinate(row, col)

        // If the neighboring coordinate contains a value that can be
        // coerced to a [SchematicItem.Number], we haven't added that
        // number to the gear ratio yet, and it's not the third (or
        // greater) number we've found, then we add (by multiplying) that
        // number to the gear ratio and add the number's ID to the set
        // of seen numbers.
        val maybeNumber = map.get(checkAt) as? SchematicItem.Number
        if (maybeNumber != null && !numbersSeen.contains(maybeNumber.id)) {
          if (numbersAdded >= 2) continue@symbol // more than two numbers
          ratio *= maybeNumber.number
          numbersSeen.add(maybeNumber.id)
          numbersAdded += 1
        }
      }

      // Only add the raio to ratios if we saw two numbers
      if (numbersAdded == 2) ratios.add(ratio)
    }

    return ratios
  }
}

class Day03(input: String) {

  // The real work is done here
  private val schematic = EngineSchematic.fromString(input)

  // In part one, we figure out which numbers really represent parts
  // and return the sum of all of them.
  fun solvePart1(): Int = schematic.partNumbers().sumOf { it.number }

  // In part two, we find the gears (which are a bit trickier) and return
  // the sum of all the gear ratios.
  fun solvePart2(): Int = schematic.gearRatios().sum()
}

Here, we iterate over the list of symbols and check around them for any number. If we find one number, that goes in the ‘gear ratio’. Same for the second one. A third one, though, and we’re out; that’s not a gear. Calculating the gear ratio for all the ‘*’ that are really gears, we just need to sum them and we’re good to go.

Wrap Up

I’ve heard this year (so far) being referred to as the “Advent of Parsing”, and there’s a certain truth to that. Granted, there’s a certain truth to that every year, but these first three days have been pretty heavy with it. It may have something to do with these first few days falling on a weekend. Regardless, it’s certainly given me an opportunity to write a decent amount of code in Kotlin, which is helping the learning process. I was delighted to find the mechanism for tagging loops and choosing which one to break/continue for the loops within loops of today’s solutions. I’d like to be writing these in a more “functional” style as opposed to the “initialize then loop” pattern I’ve got here, but I’m not sure how to do that with all the side-effects I’m engaging here. Probably just need to spend a bit more time on it, reduce with a data structure, etc.

Lastly, I’ll point out the JetBrains Livestreams for Advent of Code. I’ve found them really helpful for hearing how other people have approached these problems in the same language who have a much greater breadth of knowledge about what’s in the standard library and ecosystem. It really helps me to listen in after I’ve solved the problem (or at least worked on it) so I can more easily follow along. Give it a watch/listen!

Advent of Code 2023 - Day 02

Sat, 02 Dec 2023 00:00:00 +0000

Day 2 - Cube Conundrum

Find the problem description HERE.

The Input - Cubist Collection

It seems we’ve rounded the corner from yesterday’s “parsing is the puzzle” and now we’re back on more familiar footing. The puzzle description states that we need to keep track of games and handfuls of cubes, so that’s what we’re going to do!

/**
 * This is a data class that represents a set of colored cubes
 *
 * @property red The number of red cubes
 * @property green The number of green cubes
 * @property blue The number of blue cubes
 * @constructor Create a new [CubeSet] with the given number of [red], [blue], 
 * and [green] cubes.
 */
data class CubeSet(val red: Int, val green: Int, val blue: Int) {
  companion object {
    /**
     * Parse a [CubeSet] from a String
     *
     * @param input The string to be parsed
     * @throws IllegalArgumentException When the input string is not formatted 
     *         properly
     * @return A [CubeSet]
     */
    fun fromString(input: String): CubeSet {
      var red = 0
      var green = 0
      var blue = 0

      // Split a string like "1 red, 2 green, 3 blue" on commas and trim each.
      // For each number/color combination, split a string like "1 red" into
      // [1, "red"] and check to be sure we got the parts we were expecting. If
      // so, increase the number of cubes indicated by the color. Once all color
      // cubes are counted, return a [CubeSet] with those counts.
      val colorCounts = input.split(",").map { it.trim() }
      for (colorCount in colorCounts) {
        val parts = colorCount.split(" ")
        require(parts.size == 2) { "$colorCount does not match expected format!" }

        val count =
            parts[0].toIntOrNull()
                ?: throw IllegalArgumentException(
                  "$colorCount does not contain a valid count!"
                )
        val color = parts[1].lowercase()

        when (color) {
          "red" -> red += count
          "green" -> green += count
          "blue" -> blue += count
          else -> throw IllegalArgumentException(
            "$colorCount does not contain a valid color!"
          )
        }
      }

      return CubeSet(red, green, blue)
    }
  }
}

/**
 * This class represents one round of the [Game]
 *
 * Each round, the elf reveals a handful of cubes. This class holds the [id] of 
 * the game and maintains a list of the [handfuls] of cubes revealed by the elf.
 *
 * @property id The unique game identifier.
 * @property handfules The [CubSet]s revealed by the elf.
 * @constructor Creates a new [CubSet] with the given [id] and [handfuls] of 
 *              revealed cubes.
 */
data class Game(val id: Int, val handfuls: List<CubeSet>) {
  companion object {
    /**
     * Parse a [Game] from a line of the input file
     *
     * @param input A line from the input file.
     * @throws IllegalArgumentException When the input is malformed.
     * @return A [Game] parsed from the input line.
     */
    fun fromString(input: String): Game {
      // Input in the format of "Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 
      // 2 green". Split on the colon to get ["Game 1", "3 blue, 4 red; 1 red, 
      // 2 green, 6 blue; 2 green"].
      val mainParts = input.split(":").map { it.trim() }
      require(mainParts.size == 2) { "$input is not a valid Game format!" }
      val (gamePart, cubePart) = mainParts

      // Get the Game ID from a string like "Game 1". If this part of the input 
      // line is not formed correctly, throw an exception.
      val gameParts = gamePart.split(" ").map { it.trim() }
      require(gameParts[0] == "Game") {
        throw IllegalArgumentException("$gamePart is not a valid Game format!")
      }
      val id =
          gameParts[1].toIntOrNull() ?: throw IllegalArgumentException(
            "$gamePart does not contain a valid id!"
          )

      // Get the handfuls of cubes revealed. For each string like 
      // "1 red, 2 green, 6 blue", parse that string into a [CubeSet] and 
      // set `handfuls` to that list of cubesets.
      val handfuls = cubePart.split(";").map(CubeSet::fromString)

      return Game(id, handfuls)
    }
  }
}

class Day02(input: List<String>) {

  // Parse the input by constructing a Game from each non-empty line.
  private val parsed = input.filter { !it.isEmpty() }.map(Game::fromString)

 // ...
 
}

So, here we go. We’ve got CubSets and we’ve got Games and we can parse each of them from a line of the input. Nice.

Part One - Bag of Holding

We’ve (barely) arrived safely on an island in the sky that I kind of wish we’d known about before being launched like a pumpkin (look it up, it’s a thing). Ah well, at least we have a tour guide. And, he wants to play a guessing game with us. Our guide will be pulling cubes out of his bag and we’re supposed to figure out whether or not his bag contains more or less than some predefined number of red, green, and blue cubes. Not the worst way to spend a leisurely stroll across a sky island.

data class CubeSet(val red: Int, val green: Int, val blue: Int) {
  
  // ...

  /**
   * Determines whether this [CubeSet] is valid
   *
   * A [CubSet] is valid if the number of cubes in it can be contained in the 
   * [max] cubeset it is being compared to.
   *
   * @param max A [CubeSet] to compare against
   * @return A boolean indicating whether this [CubeSet] is valid
   */
  fun isValid(max: CubeSet): Boolean {
    return red <= max.red && green <= max.green && blue <= max.blue
  }
}

data class Game(val id: Int, val handfuls: List<CubeSet>) {

  // ...

  /**
   * Indicate whether this [Game] is valid
   *
   * A valid game is one where every revealed handful of cubes can be contained 
   * within the [max] cubeset.
   *
   * @param max A [CubeSet] to compare against
   * @return A Boolean indicating whether the [Game] is valid.
   */
  fun isValid(max: CubeSet): Boolean {
    return handfuls.all { it.isValid(max) }
  }
}

class Day02(input: List<String>) {

  private val maxCubeSet = CubeSet(12, 13, 14)

  // Parse the input by constructing a Game from each non-empty line.
  private val parsed = input.filter { !it.isEmpty() }.map(Game::fromString)

  // In part 1, we compare our games to a static maximum cubeset, determine
  // which games are valid, and return the sum of their game ids.
  fun solvePart1(): Int = parsed.filter { it.isValid(maxCubeSet) }.sumOf { it.id }

  // ...
  
}

There we go, a shiny new member function for each of our classes to determine whether a particular CubeSet is valid and therefor whether the entire Game is valid. Sum the ID’s of the valid games, and we’ve got our answer.

Part Two - In the Eye of the Beholder

Who knew a bag of cubes could be so entertaining? Well, I suppose you get very creative stranded on an island in the sky. Our tour guide clearly needed some company in a bad way. And we’re company, so now’s the chance to up the level of the game. In part 2, we need to decide on the minimum possible contents of the bag (per game) based on what we’ve seen, then provide an answer based on these contents. Sounds do-able.

data class CubeSet(val red: Int, val green: Int, val blue: Int) {
 
  // ...

  /**
   * Calculate the power of this [CubeSet]
   *
   * Power is the product of the number of red, green, and blue cubes
   *
   * @return The calculated power
   */
  fun power(): Int {
    return red * green * blue
  }
}

data class Game(val id: Int, val handfuls: List<CubeSet>) {
  
  // ...
  
  /**
   * Identify the smallest [CubSet] that can contain all [handfuls]
   *
   * Calculate the smallest number of red, green, and blue cubes that could be 
   * represented by the handfuls of cubes revealed by the elf.
   *
   * @return The smallest possible [CubeSet]
   */
  fun localMinimum(): CubeSet {
    var red = 0
    var green = 0
    var blue = 0

    // The smallest possible cubeset must contain at least as many red,
    // green, and blue cubes as revealed in any given handful of cubes.
    for (handful in handfuls) {
      red = maxOf(red, handful.red)
      green = maxOf(green, handful.green)
      blue = maxOf(blue, handful.blue)
    }

    return CubeSet(red, green, blue)
  }
}

class Day02(input: List<String>) {

  // ...

  // In part 2, we identify the smallest valid set of cubes for each game, 
  // calculate the 'power' of that minimum set, then return the sum of all
  // the power from all the games.
  fun solvePart2(): Int = parsed.sumOf { it.localMinimum().power() }
}

There we go! Again, just a couple more member functions on our two classes and we’re good to go.

Wrap Up

Now this is more in line with the difficulty level of a Day 2 Advent of Code puzzle. There’s probably a ton of minor ways this solution could be tweaked, but it boils down to parsing strings and keeping track of your data structures. I was a bit concerned after Day 1’s relative difficulty (and knowing today was a weekend), but it appears to be all for naught. As for Kotlin, I find the whole “companion object” structure for class methods to be a bit odd and I kind of miss the FromStr trait in Rust, but so far it’s felt like mostly familiar territory.

Advent of Code 2023 - Day 01

Fri, 01 Dec 2023 00:00:00 +0000

Day 1 - Trebuchet?!

Find the problem description HERE.

The Input - Numbers Every Which Way

Well, well, well… Here we are again. Another year, another catastrophic threat to Christmas cheer. Thankfully, we’ve advanced to trebuchet technology to tackle this looming crisis. It looks like this year we’ll be working to restore snow production, which will hopefully result in a few snow days! What’s that? Remote work is a thing now? Ah well, at least snow is pretty…

Our input for today is the “calibration document” for the trebuchet we’re apparently about to be fired out of (no snow days doesn’t seem like such a big sacrifice now, huh?). We need to read in a list of strings from a text file, extract all the numbers, then use the first and last number to calculate the “calibration value” on each line. Because (spoiler alert!) the parsing strategy changes a bit from part 1 to part 2, I’ll address each one individually. Instead, I’ll use this section to share my “read the input file” code I cleverly prepared ahead of time this year, and that I hope will continue to be handy.

import java.io.File
import java.net.URI

internal object Resources {
  private fun String.toURI(): URI =
      Resources.javaClass.classLoader.getResource(this)?.toURI()
          ?: throw IllegalArgumentException("Cannot find Resource: $this")
          
  fun resourceAsText(fileName: String): String = File(fileName.toURI()).readText()

  fun resourceAsLines(fileName: String): List<String> = File(fileName.toURI()).readLines()

  fun resourceAsLineChunks(fileName: String, delimiter: String = "\n\n"): List<List<String>> =
      resourceAsText(fileName).split(delimiter).map { it.lines().takeWhile { !it.isEmpty() }.toList() }

  fun resourceAsString(fileName: String, delimiter: String = ""): String =
      resourceAsLines(fileName).reduce { a, b -> "$a$delimiter$b" }

  fun resourceAsListOfInt(fileName: String): List<Int> =
      resourceAsLines(fileName).map { it.toInt() }

  fun resourceAsListOfLong(fileName: String): List<Long> =
      resourceAsLines(fileName).map { it.toLong() }
}

These aren’t terribly complicated, but they’re general enough to be useful almost every day, I suspect. We can read the input file as a single string, as a list of lines (strings), as a list of line chunks (with a delimiter), as a list of strings from a single line (with optional delimiter), as a list of integers (one per line), and as a list of longs (again, one per line). There’s a good chance I’ll come up with others over the course of the month (I’m already thinking I’d like a resourceAsParsedLines that takes a parsing function as a second argument), but as long as I get to re-use some of these, it will have been worth it.

Part One - Artistic Expression

Bad news: You’re being hoisted into a trebuchet to be launched into the sky.
Good news: The elves can’t calibrate their siege weapon! We’re saved!

Wait, did we volunteer to decipher the calibration document to help the elves propel us into the stratosphere? Guess we’d better get to it, then.

/**
 * Extracts all digit characters from a string as numbers.
 *
 * @return A list of all digits in the input String as Ints.
 */
private fun String.extractDigitsPart1(): List<Int> {
    // Take the string, convert to a list of characters, filter to
    // only characters that are digits, then convert those digit
    // characters to integers.
    return this.toList().filter(Char::isDigit).map(Char::digitToInt)
}

/**
 * Derive the calibration value from a list of numbers
 *
 * This function "concatenates" the first digit in a list of numbers and the 
 * last digit in a list of
 * numbers into a single two-digit number.
 *
 * @return The calibration value extracted from a list of numbers.
 */
private fun List<Int>.toCalibrationValue(): Int {
    // This works because the 'numbers' are all single digits. So, it's
    // the ten's place * 10 plus the one's place (times 1, technically).
    return (this.first() * 10) + this.last()
}

class Day01(input: List<String>) {

    private val input = input

    // In part one, the valid numbers in the string are all digits.
    // Take the input, extract all the digits from each line, then 
    // sum the calibration values of each line.
    fun solvePart1(): Int = input
        .map(String::extractDigitsPart1)
        .sumOf { it.toCalibrationValue() }
}

Part Two - Burning Out My Fuse Up Here Alone

I feel like we’re being a bit too accommodating when it comes to helping the elves in this endeavor. I can’t help but think that, if the trebuchet weren’t an option, we could borrow some sort of flying vehicle (perhaps reindeer-propelled) to make this trip. Probably with fewer life-threatening injuries, which would be a big plus. Must just be me. Anyway, part two asks us to parse words that represent numbers (like ‘one’ or ‘fiveight’) as well as digits from the lines of the input.

/**
 * Extract all digits from a string as numbers
 *
 * This function also extracts digits in "word" form, such as "one" or "two". 
 * Note, this function will also extract number-words whose letters overlap, 
 * such as "twoone" or "fiveight".
 *
 * @return A list of all digits in the input String as Ints.
 */
private fun String.extractDigitsPart2(): List<Int> {
    val pattern = """(?=(one|two|three|four|five|six|seven|eight|nine|\d))"""

    // Because we have to account for overlaps, I'm using the "non-consuming" regular
    // expression above. This does weird things (IMO) to the match values, causing
    // `findAll()` to return a list of values for each match where the first value
    // is an empty string. Probably just means I need to learn more about regex.
    // Regardless, the result is that I need to flatten the results and remove empty
    // strings before converting the matches to numbers.
    return Regex(pattern)
            .findAll(this)
            .flatMap { it.groupValues }
            .filter(String::isNotBlank)
            .map(String::toNumberUnchecked)
            .toList()
}

/**
 * Convert a String to an Int
 *
 * This function will numeric strings _and_ words that represent digits into
 * integers.
 *
 * @return The Int representation of a String
 */
private fun String.toNumberUnchecked(): Int {
    // I wouldn't recommend using this in production anywhere, since we're
    // not actually checking to see whether any numeric strings are
    // (a) valid numbers or (b) single digits. Just gotta count on the
    // puzzle input for this one.
    return when (this) {
        "one" -> 1
        "two" -> 2
        "three" -> 3
        "four" -> 4
        "five" -> 5
        "six" -> 6
        "seven" -> 7
        "eight" -> 8
        "nine" -> 9
        else -> toInt()
    }
}

class Day01(input: List<String>) {

    private val input = input

    // In part one, the valid numbers in the string are all digits
    fun solvePart1(): Int = input
        .map(String::extractDigitsPart1)
        .sumOf { it.toCalibrationValue() }

    // In part two, we also have to account for "number-words" like "one" 
    // and "twone"
    fun solvePart2(): Int = input
        .map(String::extractDigitsPart2)
        .sumOf { it.toCalibrationValue() }
}

I may or may not have submitted an incorrect answer for part two, re-read the example input (suspiciously a different example than part one), called Eric Wastl an unkind name under my breath, then proceeded to figure out how to parse ’twone’ into [2, 1].

Wrap Up

Another year, another set of coding puzzles! From a historical perspective, Day 1 this represents a bit of a bump in difficulty level from previous years. I don’t know if this means we’re in for a more challenging year overall or if this is a deliberate attempt to keep the LLMs at bay. Either way, I know I spent more time on a Day 1 puzzle today than I have in the past.

This year I’m picking up a complete new (to me) language in Kotlin. So far, the biggest challenge has been figuring out enough about how Maven works to get my project setup in place, but that’s probably a me issue. I’m really excited to learn a lot this year and looking forward to giving Kotlin a workout.

Finally, if you enjoy Advent of Code as much as I do, consider helping out with this completely free (to use, not to run) educational and community event. And, if you’re not in a position to support financially (or even if you are), you can support the community over on the r/adventofcode with code reviews, advice, visualizations, or hilarious memes. Happy Holidays!

Advent of Code - Getting Started

Tue, 28 Nov 2023 00:00:00 +0000

The weather outside isn’t quite frightful yet, but the most wonderful time of year is fast approaching. That’s right, it’s almost time for Advent of Code! Like prior years, I’ll personally be using this event to learn a new programming language. This year, it’s Kotlin. And, as usual, I’ll be blogging each day’s puzzle, but I thought I’d kick this year off with a brief walkthrough of how (and a bit of why) I set up my own project repository for AoC. Having completed 8 years’ worth of puzzles now, I’ve found there’s a lot of value in a bit of setup beforehand.

Orientation

This guide will make a lot more sense if you’re already familiar with the setup and style of Advent of Code. Briefly, each day from December 1st through December 25th, a new puzzle will be made available. Each puzzle will have two parts. Generally, the second part is a slightly/somewhat more complicated version of the first part that requires a bit of re-factoring of the first part to make it more flexible or more efficient. Unlike sites like LeetCode or CodeWars, you won’t submit your code for each puzzle. Instead, each part has a definite answer that you can arrive at using any programming language (or other tool) at your disposal. These answers are submitted on the Advent of Code site. The input for each day is provided as a downloadable text file (of which there are many variations) and you’ll use the same input for both parts. Each part you solve earns you a “star”, for two “stars” per day which is fifty “stars” over the course of the event. Generally, the difficulty of the puzzles increases each day, with larger “jumps” in difficulty on the weekends.

Because all the work for your solution is done locally, it’s helpful to organize your local project files. A quick internet search of “ Advent of Code Project Template” is likely to give you a lot of options, especially for more popular languages. If this is your first Advent of Code, then I’d recommend picking one of those (after reading this article, of course!).

Let’s Git Started

Probably the best place to start is deciding that you’re going to use version control, then deciding where you plan on hosting your project long term. GitHub is likely to be a popular choice, but GitLab, BitBucket, or any of the other VCS-hosting platforms works just as well. Frankly, you don’t need to host/share your code online, but it is nice to be able to share your code easily, especially if you decide to ask for help (more on that later).

Since I tend to use different languages for different years, I like to set up a repository for each year and include each year as a submodule within a single “parent” repository for organization. Here’s mine in case you’re curious, but other than a README and links to the submodules, there’s not much there.

One final note about repositories: Eric Wastl, the creator and producer of Advent of Code and Advent of Code puzzles, has requested that individual inputs not be included in your repository. I honestly need to clean up some of my older repositories, but an easy way to do this is to add the input files (or folders) to your .gitignore file.

Building a Foundation

Once I have a repository, it’s time to set up the project. Now, this step is going to vary widely depending on the language you’ll be using to solve the puzzles. Many languages have at least one project template, some with scripts or applications to set up a project directory. If you have multiple options, I recommend keeping it as simple as possible. That said, there are a couple of considerations for project setup. I like to have:

Clear separation between the code for each day’s puzzle.
A testing framework/harness, with support for unit testing part one and part two of each day.
Optionally, support for benchmarking the performance of your solutions.

I don’t always care about absolute performance, but one year I had set myself a goal of writing reasonably efficient Rust code, so I made sure to include benchmarking. If you’re looking at my repository for inspiration, ignore the setup for 2020. That was my first year doing Advent of Code, and the setup is kind of garbage. Instead, check out the project setups below. While there’s definitely some variation year-to-year and language-to-language, as long as you keep your code organized, you’re going to have a better time.

Julia Setup

In 2021, I solved the puzzles in Julia. I generally split the code for each day into three parts: (1) reading and parsing the input, (2) solving part one, (3) solving part two. In my Julia project, I have a separate file for each part and include the input parsing code in a file named “DayXX.jl” (where “XX” is “01” for day 1, “02” for day 2, “25” for day 25, etc.) to combine these three parts into a single module. There are some other scripts in there that I’ll discuss in the next section.

<project root>
├─inputs
│ └─DayXX
│   ├─input.txt
│   └─test.txt
├─src
│ ├─DayXX
│ │ ├─DayXX.jl
│ │ ├─Part01.jl
│ │ └─Part02.jl
│ ├─Benchmark.jl
│ ├─JuliaAdventOfCode.jl
│ └─RunAll.jl
├─tests
│ ├─DayXXTests.jl
│ └─runtests.jl
├─Manifest.toml
└─Project.toml

Rust Setup

In 2022, I solved the puzzles in Rust. Again, I’ve got Rust modules for each day, split into input parsing, part one, and part two code for each day (notice a pattern?). I’ve also got code for benchmarking this year. One thing to note in this Rust setup is that Rust allows (and even encourages) test code to be written alongside the code being tested, so there’s no separate folder for tests.

<project root>
├─benches
│ └─all_days.rs
├─input
│ └─XX
│   ├─input.txt
│   └─test.txt
├─src
│ ├─dayXX
│ │ ├─input.rs
│ │ ├─mod.rs
│ │ ├─part1.rs
│ │ └─part2.rs
│ ├─bin.rs
│ └─lib.rs
├─Cargo.toml
└─README.md

Kotlin Setup

Here’s what I’m planning to use for 2023. I realize it’s a bit different from what you might find elsewhere since I’m using Maven instead of Gradle, but I found a project template I liked using Maven.

<project root>
├─src
│ ├─main
│ │ ├─dev.ericburden.aoc2023
│ │ │ ├─Day##.kt
│ │ │ └─Resources.kt
│ │ └resources
│ │   └─day##.txt
│ └─test
│   ├─dev.ericburden.aoc2023
│   │ └─Day##Test.kt
│   └resources
│     └─day##ex##.txt
├─setup-day
├─pom.xml
└─README.md

Automating Common Tasks

One of the benefits to splitting your project up by day is that you’ll find yourself doing some of the same things every day. For me, the usual workflow includes:

Creating a template for the current day’s puzzles, including tests.
Downloading the input.
Copy/pasting the example input(s) into a file.
Attempting to solve part one.
Testing the part one solution using the example input and expected output (preferably by adding a unit test for the example input)
Checking that the part one solution works on the real input.
Probably tweaking the part one solution until it does work on the real input.
Memorializing the part one solution in a test case (so we don’t accidentally break it while working on part two).
Copy/pasting the example for part two (if different).
Attempting to solve part two.
Testing the part two solution against the example(s).
Checking that the part two solution works on the real input.
Memorializing the part two solution in a separate test case.
Running all the example and part one/two tests to confirm they all still work.
Celebrate!

Input

Thankfully, some of these tasks can be automated, most easily the parts where you create a template for the current day and download the input. A lot of the boilerplate for the solution and tests can be generated as well. You can even automate the part where you submit your answers, but I’ve never felt like I needed that. This year, I’ve written a small shell script that relies on the aoc-cli tool to fetch inputs. I’m including the contents of that script below because, by changing out the text of the templated file contents, it could be easily adapted to just about any setup.

#! /bin/bash

DAY=$1
[[ -z $2 ]] && YEAR=2022 || YEAR=$2

# Day must be passed as an argument
if [ -z "$DAY" ]; then
	echo "Please provide the day as an argument."
	exit 0
fi

# Don't try to setup days before the 1st or after the 25th
if (("$DAY" > 25 || "$DAY" < 1)); then
	echo "There's no Day $1 in the advent calendar!"
	exit 0
fi

# Don't try to set up years with no AoC (or in the future)
if ((YEAR < 2015 || YEAR > $(date +"%Y"))); then
	echo "The year passed must be a valid AoC year!"
	exit 0
fi

# Warn and quit if no .cookie file found
COOKIE=.cookie
if [ ! -f "$COOKIE" ]; then
	echo "Store your AoC session cookie in '.cookie'!"
	exit 0
fi

# Create the class files for the given day
PADDED=$(printf "%02d" "$DAY")
SOLUTION_PATH="src/main/kotlin/dev/ericburden/aoc2023/Day${PADDED}.kt"
TEST_PATH="src/test/kotlin/dev/ericburden/aoc2023/Day${PADDED}Test.kt"

if [ -f "SOLUTION_PATH" ]; then
	echo "You've already set up Day $DAY !"
	exit 0
fi

# Template for the solution file
cat >"$SOLUTION_PATH" <<EOL
package dev.ericburden.aoc2023

class Day${PADDED}(input: String) {

    private val parsed = null

    fun solvePart1(): Int = 0

    fun solvePart2(): Int = 0
}
EOL

# Template for the test file
cat >"$TEST_PATH" <<EOL
package dev.ericburden.aoc2023

import dev.ericburden.aoc2023.Resources.resourceAsText
import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Disabled
import org.junit.jupiter.api.DisplayName
import org.junit.jupiter.api.Nested
import org.junit.jupiter.api.Test

@DisplayName("Day ${DAY}")
class Day${PADDED}Test {

    private val example1 = resourceAsText("day${PADDED}ex01.txt")
    private val input = resourceAsText("day${PADDED}.txt")
    private val part1ExampleResult = 0
    private val part1Answer = 0
    private val part2ExampleResult = 0
    private val part2Answer = 0

    @Nested
    @DisplayName("Part 1")
    inner class Part1 {
        @Test
        fun \`Matches example\`() {
            val answer = Day${PADDED}(example1).solvePart1()
            assertThat(answer).isEqualTo(part1ExampleResult)
        }

        @Test
        @Disabled
        fun \`Actual answer\`() {
            val answer = Day${PADDED}(input).solvePart1()
            assertThat(answer).isEqualTo(part1Answer)
        }
    }

    @Nested
    @DisplayName("Part 2")
    inner class Part2 {
        @Test
        @Disabled
        fun \`Matches example\`() {
            val answer = Day${PADDED}(example1).solvePart2()
            assertThat(answer).isEqualTo(part2ExampleResult)
        }

        @Test
        @Disabled
        fun \`Actual answer\`() {
            val answer = Day${PADDED}(input).solvePart2()
            assertThat(answer).isEqualTo(part2Answer)
        }
    }
}
EOL

# Fetch the input with aoc-cli
RESOURCE_PATH=src/main/resources
mkdir -p $RESOURCE_PATH # Ensure directory exists
INPUT_PATH="${RESOURCE_PATH}/day${PADDED}.txt"
aoc -s $COOKIE -y "$YEAR" -d "$DAY" -I -i "$INPUT_PATH" -o download

# Create a blank file for the first example (others can be created manually)
touch "src/test/resources/day${PADDED}ex01.txt"

I suspect more could be done here to extract the examples into their own files as well.

Output

Most of my previous setups also include a facility to run a script or executable that accepts the day (1-25) as an argument, runs the code for that day’s puzzle, and outputs the result. This isn’t super useful in and of itself, but it’s kind of a fun feature. This is mostly useful if you’re working with someone else to help debug their solution by giving you an easy way to run another input through a working algorithm.

You could also have your script/binary report benchmarking results, which would be a bit more useful. Here’s a direct link to my Rust binary that does this exact thing, in you’re interested. To run all days, it would be invoked like ./advent_of_code_2023 --all --timed.

We’re All In This Together

With the setup in place, the last nugget I’d like to leave you with is to point out that Advent of Code is a very popular coding event with hundreds of thousands of participants each year. One of the implications to this is that, if you’re even remotely on pace with the daily puzzles, there’s bound to be numerous other people working on the same puzzle as you are at the same time. In addition, there’s a lot of content out there for at least the mainstream programming languages. I mentioned at the top that I write up my solutions each year, but I’m definitely not the only (or even the most interesting) source of write-ups out there. For Kotlin, I’ve already seen that JetBrains has a set of livestreams planned, and I know they’re not the only ones. In addition, the r/adventofcode Sub-Reddit is extremely welcoming and hosts a daily “Solution MegaThread” in addition to encouraging participants to post questions about puzzles they’re having trouble with. One “pro-tip” that I’d offer is that, if you’re stuck on one of the daily puzzles, go scan the Solution MegaThread and just see what people are saying about the puzzle. Often, without even looking at their code, you can get enough of a hint to get you through. Alternatively, you can read someone else’s solution in a different language.

The Wrap-Up

I’ll close by pointing out once again that Advent of Code is a lot less structured than some other coding puzzles out there. This is by design. Advent of Code, according to the creator, is meant to be a tool for learning in community. My experience has been that this is absolutely true and the most satisfying way for me to engage with this event. I encourage everyone who is even vaguely interested in writing code and solving puzzles to participate and to participate to the end. Even if you need to read a blog post or watch a video to understand and implement a solution to one (or more) of the puzzles, as long as you’re learning, you’re getting the benefit of Advent of Code. Frankly, I’d say you’re probably learning something even if you’re copying someone else’s code, so long as you’re taking the time to understand what it’s doing (and probably re-factoring it to be easier to read along the way). Ultimately, Advent of Code should be fun and educational, so as long as that’s what you’re getting out of it, I’d say you’re on the right track.

I hope this brief introduction to setting up an Advent of Code project has been useful for you and helps smooth out some of the more tedious bits so you can get to the good stuff even faster. Happy coding, and Happy Holidays!

Advent of Code 2022 - Day 25

Thu, 29 Dec 2022 00:00:00 +0000

It’s that time of year again! Just like last year, I’ll be posting my solutions to the Advent of Code puzzles. This year, I’ll be solving the puzzles in Rust. I’ll post my solutions and code to GitHub as well. After finishing last year (and 2015-2019) in Julia, I needed to spend some time with Rust again! If you haven’t given AoC a try, I S encourage you to do so along with me!

Day 25 - Full of Hot Air

Find the problem description HERE.

The Input - CABFuN: Clever Acronym for Base-Five Numbers

One of the most straightforward parsing days of the year! I though I might need to break out nom one more time, but no such luck. Given that a SNAFU number is a series of “numerals” (characters), it makes sense to represent them as Strings.

/// This represents one of our SNAFU numbers, which is just a String
/// in a Wrapper so we can have custom `From` implementations.
#[derive(Debug, Clone)]
struct Snafu(String);

/// Converting a line from the input into a Snafu is super complicated.
impl From<&str> for Snafu {
    fn from(line: &str) -> Self {
        Snafu(line.to_string())
    }
}

const INPUT: &str = include_str!("../../input/25/input.txt");

/// Parse that input!
 fn read() -> Vec<Snafu> {
    INPUT.lines().map(Snafu::from).collect::<Vec<_>>()
}

Mighty parsing indeed!

Part One - Great, Now There’s Another Standard

Come on, Bob! Aw, don’t look at me that way… I can’t stay mad at you! Besides, it’s not Bob’s fault that the manufacturer decided to invent their own numbering system. Not cool, manufacturer, not cool. Speaking of cool, we really need to add up these SNAFU numbers so we can calculate how much fuel each balloon with take so we can warm up that fuel and beat it!

/// Solve Day 25, Part 1
pub fn solve(input: &[Snafu]) -> String {
    let fuel_cost: i128 = input.iter().cloned().map(i128::from).sum();
    let snafu_cost = Snafu::from(fuel_cost);
    snafu_cost.0
}

/// Unit conversion from a SNAFU number to a base-10 integer. This is a pretty
/// common algorithm for converting base-whatever to decimal.
impl From<Snafu> for i128 {
    fn from(snafu: Snafu) -> Self {
        let mut total = 0;
        for (pow, glyph) in snafu.0.chars().rev().enumerate() {
            let mult = match glyph {
                '2' => 2,
                '1' => 1,
                '0' => 0,
                '-' => -1,
                '=' => -2,
                _ => unreachable!(),
            };
            total += 5i128.pow(pow as u32) * mult;
        }
        total
    }
}

/// Unit conversion from a decimal integer into a SNAFU number. This is a much
/// less common (to me) operation. The tricky bit is handling the fact that we have 
/// digits whose value is centered around zero instead of anchored at zero on the
/// least significant place. For a normal base-5 conversion, I'd take the result 
/// of the remainder % 5, then divide by 5 for each digit until no remainder was
/// left. Apparently, adding two each round lets us shift the digits. I'm not
/// 100% sure why this works, but it works. Math, amirite? This solution was inspired
/// by Google searches about "balanced ternary" number systems.
impl From<i128> for Snafu {
    fn from(number: i128) -> Self {
        let mut remainder = number;
        let mut out = String::default();
        while remainder > 0 {
            let glyph = match remainder % 5 {
                0 => '0',
                1 => '1',
                2 => '2',
                3 => '=',
                4 => '-',
                _ => unreachable!(),
            };
            out.push(glyph);
            remainder += 2;  // This works for some reason.
            remainder /= 5;
        }
        Snafu(out.chars().rev().collect::<String>())
    }
}

Part Two - Auld Lang Syne

This is my third year with Advent of Code, and as I set in reflection over this year’s event, the thing that stands out to me the most is how big an impact AoC has as a community event. Don’t get me wrong, I love a good puzzle, I really enjoy coding puzzles, and I’m happy to set time aside put my head down to work on something fun and interesting all by myself. Thing is, though, there’s something about knowing that other people are working, thinking, struggling, solving, succeeding, failing, and re-starting at the same time as you that’s really invigorating. For one thing, outside of actual work projects or groups that are heavily invested in an open source project, it’s a rare thing to have people from all over who can look at your code and already be read in on exactly what you’re trying to accomplish. It’s like the world’s biggest code review! I’ve been really encouraged by engaging with the community on r/adventofcode and the #AdventOfCode hashtag on Mastodon. There are so many people doing so many interesting things, and it’s nice to see them all engaged in the same thing at the same time!

I’ve definitely gotten more engagement this year with the blog, which is encouraging for me as well. I get a lot of satisfaction out of helping others, and if I can do that while over-explaining a bit of code, so much the better! Honestly, writing this blog series is the biggest reason I’m able to finish all the days. Knowing that if I quit somebody is going to notice really helps keep me going. I don’t really imagine anyone is actually counting on me to finish all the days, but doing it in public really is a good approach for anything you really do want to finish. Speaking of finishing things, I went back and earned the rest of those stars this past year! I didn’t blog about them, because that would be a lot and probably not that interesting this long after they were posted, but I’m officially a member of the 400 star club! I solved years 2015 - 2019 in Julia, which I’d heartily recommend to anyone who’s considering learning that language. I know a lot of folks lean on Python for Advent of Code (and other puzzles), but I never found Julia to lack any convenience or ergonomics. In fact, the much better lambda syntax and rich standard library (including multi-dimensional arrays) really provide a powerful toolbox for problem-solving. You can check out the code yourself if you’d like here.

Of course, all that Julia meant that I was itching to try something else this year. I used the 2020 puzzles to learn Rust after the fact, initially solving them in R, and I’ve practiced a bit with Rust since then, primarily using it to implement functionality that I could call from R because trying to use C or C++ interop for someone who doesn’t know either language was a truly frustrating experience. I had hoped that, given my experience with Advent of Code and my budding familiarity with Rust, that I’d be able to finish all 25 days in Rust first this year, and I’m really proud of myself that I did. Not only that, I used Advent of Code to learn the nom parser combinator crate. While I struggled a bit with it in the early days, some of the later days really benefited from that style of parsing and eventually it felt like nom made approaching the solutions a bit easier, which is exactly what I was hoping for. A few other notable crates made appearances, such as rayon and itertools, but nom was definitely the most widely used. I also spent some time ahead of December 1st preparing my project setup, and I’d have to say that’s my #1 Advent of Code tip for anyone who plans to solve all the puzzles. If you’re not sure how, copy someone else’s. Just the amount of time and energy you save by not needing to think about how to structure your project each day, especially when you’re using a language as relatively strict as Rust, definitely makes it worth it. I knew when I started tackling the old years in Julia that I was going to want at least some templating for each day/year and a consistent way to run tests and benchmarks, and I basically just copied that idea into my Rust setup this year. There are definitely improvements I’d make, but having something is a lot better than nothing.

If you’re interested, you can find all the code from this blog series on GitHub, please feel free to submit a pull request if you’re really bored. Happy Holidays!

Advent of Code 2022 - Day 24

Wed, 28 Dec 2022 00:00:00 +0000

Day 24 - Unstable Diffusion

Find the problem description HERE.

The Input - Valley Girls Elves

Today’s input is a variation on the theme of “2D maps where each character means a different thing”, which, in this case, represents a walled valley with “blizzards” blowing around inside it. The puzzle text sort of hints at this, but it turns out that the examples and the actual inputs both represent states that will eventually cycle back around to where they began. This means that our input struct will essentially be a 3-dimensional vector where the third dimension is time (in a loop). For my input, that was 600 different arrangements of the 2D valley before it cycled around to the beginning.

use anyhow::{bail, Error, Result};
use itertools::Itertools;
use std::collections::{HashMap, HashSet};

/// Represents the direction in which a particular Blizzard is blowing.
/// We have impls to allow converting to/from single-bit u8 values so
/// that a set of four directions can be represented as a u8.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
enum Direction {
    Down,
    Left,
    Up,
    Right,
}

impl TryFrom<u8> for Direction {
    type Error = Error;

    fn try_from(value: u8) -> Result<Self, Self::Error> {
        match value {
            1 => Ok(Direction::Down),
            2 => Ok(Direction::Left),
            4 => Ok(Direction::Up),
            8 => Ok(Direction::Right),
            _ => bail!("No direction corresponding to {value}!"),
        }
    }
}

impl Direction {
    /// Convert a Direction to a single-bit u8 value
    const fn value(&self) -> u8 {
        match self {
            Direction::Down => 1,
            Direction::Left => 2,
            Direction::Up => 4,
            Direction::Right => 8,
        }
    }

    /// Get an array of all four Directions
    const fn all() -> [Direction; 4] {
        [
            Direction::Down,
            Direction::Left,
            Direction::Up,
            Direction::Right,
        ]
    }
}

/// Represents one or more blizzards occupying a single space in the Valley.
/// Because there's only one blizzard per space in the input, there can ever
/// only be one blizzard per direction in a single space at any time after
/// the blizzards begin moving in the Valley. So, we never need more than
/// the presence/absence of each of the four directions per Blizzard space.
#[derive(Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
struct Blizzard(u8);

impl Blizzard {
    fn from(direction: Direction) -> Self {
        Blizzard(direction.value())
    }

    fn direction(&self) -> Result<Direction> {
        Direction::try_from(self.0)
    }

    /// Add a direction to the current Blizzard
    fn add(&mut self, direction: Direction) {
        self.0 |= direction.value();
    }

    /// Check if the Blizzard space has a Blizzard blowing in a
    /// particular direction.
    fn has(&self, direction: Direction) -> bool {
        self.0 & direction.value() > 0
    }
}

/// Represents a single space in the Valley. Can either be a space with Blizzards
/// blowing in one or more directions, an impassable Wall, or an Empty space where
/// the elven expedition can walk.
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
enum Space {
    Blizzard(Blizzard),
    Wall,
    Empty,
}

/// Represents the entire Valley and all the Blizzards blowing through it at a
/// given point in time.
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
struct Valley {
    rows: usize,
    cols: usize,
    spaces: Vec<Vec<Space>>,
}

/// Produce a new Valley from a 2D grid of Spaces.
impl From<Vec<Vec<Space>>> for Valley {
    fn from(spaces: Vec<Vec<Space>>) -> Self {
        let rows = spaces.len();
        let cols = spaces.first().map(|line| line.len()).unwrap_or_default();
        Valley { rows, cols, spaces }
    }
}

impl From<&str> for Valley {
    fn from(input: &str) -> Self {
        let mut spaces = Vec::new();
        for line in input.lines() {
            let row = line
                .chars()
                .map(|glyph| match glyph {
                    '>' => Space::Blizzard(Blizzard::from(Direction::Right)),
                    '<' => Space::Blizzard(Blizzard::from(Direction::Left)),
                    '^' => Space::Blizzard(Blizzard::from(Direction::Up)),
                    'v' => Space::Blizzard(Blizzard::from(Direction::Down)),
                    '.' => Space::Empty,
                    '#' => Space::Wall,
                    _ => unreachable!(),
                })
                .collect::<Vec<_>>();
            spaces.push(row);
        }

        Valley::from(spaces)
    }
}

impl Valley {
    /// Produce a clone of this Valley with its state advanced by one minute. All
    /// Blizzards move forward by one space in the direction they are facing,
    /// wrapping around the Valley when they encounter a Wall.
    fn advance(&self) -> Self {
        // Creates a new mutable clone of this Valley with only Empty Spaces
        let Valley { rows, cols, spaces } = self;
        let mut new_spaces = vec![vec![Space::Empty; *cols]; *rows];
        let mut new_state = Valley::from(new_spaces);

        // For each Space in the current Valley, update the appropriate space in the
        // new state. Move Blizzards and set Walls. Skip the Empties, since all the
        // Spaces in the new state are already Empty.
        for (row, col) in (0..*rows).cartesian_product(0..*cols) {
            match spaces[row][col] {
                Space::Blizzard(blizzard) => {
                    for direction in Direction::all() {
                        if !blizzard.has(direction) {
                            continue;
                        }
                        let (new_row, new_col) = self.next_position(row, col, direction);
                        new_state.add_blizzard(new_row, new_col, direction);
                    }
                }
                Space::Wall => new_state.spaces[row][col] = Space::Wall,
                Space::Empty => continue,
            }
        }

        // Return the new Valley
        new_state
    }

    /// Given a starting row and column and a Direction to move, return the row
    /// and column where you'd end up if you moved in that Direction.
    fn next_position(&self, row: usize, col: usize, direction: Direction) -> (usize, usize) {
        match direction {
            // Wrapping for increasing rows/columns
            Direction::Down => ((row % (self.rows - 2)) + 1, col),
            Direction::Right => (row, (col % (self.cols - 2)) + 1),

            // Wrapping for decreasing rows/columns
            Direction::Left => match col - 1 {
                0 => (row, self.cols - 2),
                _ => (row, col - 1),
            },
            Direction::Up => match row - 1 {
                0 => (self.rows - 2, col),
                _ => (row - 1, col),
            },
        }
    }

    /// Given a row and column and the Direction a blizzard is blowing, add that
    /// blizzard Direction to that Space. If the Space is empty, convert it to a
    /// Blizzard. If there's already a Blizzard there, just add the new Direction
    /// to the existing Blizzard. Attempts to add a Blizzard to a Wall will
    /// definitely fail.
    fn add_blizzard(&mut self, row: usize, col: usize, direction: Direction) {
        match &mut self.spaces[row][col] {
            Space::Blizzard(v) => v.add(direction),
            Space::Wall => panic!("Tried to add a blizzard to a wall!"),
            Space::Empty => self.spaces[row][col] = Space::Blizzard(Blizzard::from(direction)),
        }
    }
}

const INPUT: &str = include_str!("../../input/24/input.txt");

/// Parse the initial Valley state from the input, then advance the state
/// minute-by-minute until we reach a state we've seen before. That's right,
/// the state of the Valley cycles! This way, we can have in memory a map
/// of which Spaces are Empty and which ones have Blizzards for each point
/// in time. This means we don't need to re-calculate each state on the fly,
/// potentially re-creating the same state multiple times. Store the Valley
/// states in a Vector where the index indicates the minute at which that
/// state is valid.
fn read() -> Vec<Valley> {
    let mut valley = Valley::from(INPUT);
    let mut valley_states = Vec::new();
    let mut seen_states = HashSet::new();
    while !seen_states.contains(&valley) {
        seen_states.insert(valley.clone());
        valley_states.push(valley.clone());
        valley = valley.advance()
    }
    valley_states
}

The most difficult part was the fact that the start and end spaces are embedded in the top and bottom walls. Otherwise, I’d be tempted to just ignore the walls and only use the inner portion of the map, It’d make wrapping the blizzards around a lot easier. Regardless, now that we’ve generated the entire map, we have everything we need to solve the puzzle.

Part One - Walk The Line

Mission accomplished! Time to bug out. Unfortunately, out is on the other side of a box valley filled with completely predictably blowing storms. Ah, man! Well, at least the elephants and monkeys agreed to stay at the grove and tend to things there. Miscommunication at a sensitive time like this could be disastrous. We have our map, it’s time to calculate a shortest path!

use core::cmp::Reverse;
use std::collections::{BinaryHeap, HashMap};

/// Solve Day 24, Part 1
fn solve(input: &[Valley]) -> u32 {
    let first_state = input.get(0).expect("Valley should have an initial state!");

    // All examples and input have the start Space at index (0, 1) and the end
    // Space on the bottom row, next to the last column.
    let start_at = Expedition(0, 1);
    let end_at = Expedition(first_state.rows - 1, first_state.cols - 2);

    // Calculate the length of the shortest path through the Valley.
    if let Some(minutes) = start_at.shortest_path(end_at, 0, input) {
        return minutes as u32;
    }

    // Unless we can't find a path. Then, freak out! This doesn't happen,
    // though. Not anymore...
    panic!("Could not find a way through the valley. Died of frostbite!");
}

/// Represents the location of the elven Expedition through the Valley.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
struct Expedition(usize, usize);

impl Expedition {
    /// Given the current location of the elves and a state of the Valley,
    /// determine which next steps are possible, in order to avoid landing
    /// on a Space with an active Blizzard. There are a maximum of five
    /// possible moves, including waiting.
    fn possible_next_steps(&self, valley: &Valley) -> [Option<Expedition>; 5] {
        let Expedition(row, col) = *self;
        let mut possible_steps = [None; 5];

        // Attempt to move to the left
        if let Space::Empty = valley.spaces[row][col - 1] {
            possible_steps[0] = Some(Expedition(row, col - 1));
        }

        // Attempt to move to the right
        if let Space::Empty = valley.spaces[row][col + 1] {
            possible_steps[1] = Some(Expedition(row, col + 1));
        }

        // The upward move needs to account for the fact that the
        // final space is in the top row, which means that moving into
        // the top row is possible.
        if row > 0 {
            if let Space::Empty = valley.spaces[row - 1][col] {
                possible_steps[2] = Some(Expedition(row - 1, col));
            }
        }

        // The downard move needs to account for the beginning space
        // being on the last row, which means that moving into the last row
        // is possible.
        if row < (valley.spaces.len() - 1) {
            if let Space::Empty = valley.spaces[row + 1][col] {
                possible_steps[3] = Some(Expedition(row + 1, col));
            }
        }

        // Waiting is a necessary option if there's nothing in our current space
        if let Space::Empty = valley.spaces[row][col] {
            possible_steps[4] = Some(Expedition(row, col));
        }

        possible_steps
    }

    /// Find the shortest path from this Expedition's location to the `target`,
    /// assuming we start the journey at minute `start_time`. Pass in a reference
    /// to the time states of the Valley so we can know which Spaces are Empty
    /// for each minute. It's a Dijkstra's implementation.
    fn shortest_path(
        &self,
        target: Expedition,
        start_time: usize,
        valley_states: &[Valley],
    ) -> Option<usize> {
        // Sort locations in the Heap by the least number of minutes spent. Uniquely
        // identify states along the path by the location of the Expedition for a
        // given state of the Valley.
        let mut open = BinaryHeap::from([(Reverse(start_time), *self)]);
        let mut minutes = HashMap::from([((*self, start_time % valley_states.len()), start_time)]);

        // So long as there are states to explore, take the one with the fewest
        // number of minutes passed.
        while let Some((Reverse(minutes_passed), expedition)) = open.pop() {
            // If we've found the end, return the number of minutes passed
            if expedition == target {
                return Some(minutes_passed);
            }

            // Get the state of the Valley in the next minute to identify
            // which Spaces are available to be moved to.
            let state_idx = (minutes_passed + 1) % valley_states.len();
            let state = &valley_states[state_idx];

            // Check each next step to see if this is the fastest we've gotten
            // to that state. If so, keep it and add it to the heap. Otherwise,
            // keep moving on.
            for step in expedition.possible_next_steps(state).into_iter().flatten() {
                let next_minutes = minutes_passed + 1;
                let curr_minutes = *minutes.get(&(step, state_idx)).unwrap_or(&usize::MAX);
                if next_minutes >= curr_minutes {
                    continue;
                }
                open.push((Reverse(next_minutes), step));
                minutes.insert((step, state_idx), next_minutes);
            }
        }

        None // Something has gone terribly wrong...
    }
}

No sweat, we’ve solved problems like this before already this year. Let’s see what part two is like.

Part Two - There and Back Again

You forgot what!? Dude, we’re literally on our way out of the jungle. We’ll be back at the North Pole in days! Besides, we all know that Bazingles over there has plenty of snacks to share, we figured that out on Day 1! Ugh, fine, I’ll go back and get them. But you owe me!

/// Solve Day 24, Part 2
fn solve(input: &[Valley]) -> u32 {
    let first_state = input.get(0).expect("Valley should have an initial state!");

    // All examples and input have the start Space at index (0, 1) and the end
    // Space on the bottom row, next to the last column.
    let start_at = Expedition(0, 1);
    let end_at = Expedition(first_state.rows - 1, first_state.cols - 2);

    // Start at zero minutes and move from the start to the end.
    let Some(minutes) = start_at.shortest_path(end_at, 0, input) else {
        panic!("Could not find a way through the valley. Died of frostbite!"); 
    };

    // Turn around and head back to the start.
    let Some(minutes) = end_at.shortest_path(start_at, minutes, input) else {
        panic!("Could not find a way back! Died in a blizzard!"); 
    };

    // Then turn around and head back to the end again.
    let Some(minutes) = start_at.shortest_path(end_at, minutes, input) else {
        panic!("Could not find a way back! Died of embarassment!"); 
    };

    // Return the total number of minutes it took to travel all that way.
    minutes as u32
}

Good thing we added that start_time argument to our shortest path function. Now we can start searching from any point in time. Turns out, it wasn’t so bad retrieving those snacks. Definitely going to extract that favor from that elf, though.

Wrap Up

Pathfinding with a twist! A nice, classic Advent of Code puzzle for Christmas Eve. There’s something comforting about that, really. Today’s puzzle would definitely have been more challenging without realizing that the state of the valley was on a cycle. In the end, though, Dijkstra’s with a twist is definitely a fun way to finish out the last day with two whole parts. Merry Christmas!

Advent of Code 2022 - Day 23

Tue, 27 Dec 2022 00:00:00 +0000

Day 23 - Unstable Diffusion

Find the problem description HERE.

The Input - Go for the Grove

No nom today, either, but a whole lot of input parsing anyway! The main thing here is that we’re going to need to keep up with which elves are going to be able to move and which ones aren’t because we have the same individuals from one round to the next. To try to keep run times down as much as possible, we’ve got one big struct for managing state that we’ll mutate from one round to the next, the Grove.

use std::collections::{HashMap, HashSet};
use std::iter::{Enumerate, Map};
use std::str::Chars;

/// Represents the position of an Elf in the Grove
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
struct Position(isize, isize);

/// Some convenience functions for working with the newtype Position.
/// I'm giving this approach a test-drive, since I don't really love
/// how Rust needs you to make the struct members public in order to
/// make a new struct, like Position(x, y). This way, I can just make
/// a public function, instead.
impl Position {
    fn new(x: isize, y: isize) -> Self {
        Self(x, y)
    }

    fn inner(&self) -> (isize, isize) {
        (self.0, self.1)
    }
}

/// Represents the cardinal and secondary directions that matter for
/// today's puzzle.
#[derive(Debug, Clone, Copy)]
enum Direction {
    North,
    NorthEast,
    East,
    SouthEast,
    South,
    SouthWest,
    West,
    NorthWest,
}

/// Represents the presence/absence of other elves in the eight spaces
/// surrounding a given position. The middle element of the middle array
/// is pretty much ignored.
#[derive(Debug, Clone, Copy)]
struct Surroundings([[bool; 3]; 3]);

impl Surroundings {
    fn new(surroundings: [[bool; 3]; 3]) -> Self {
        Surroundings(surroundings)
    }

    fn inner(&self) -> [[bool; 3]; 3] {
        self.0
    }
}

/// Represents an indicator for which direction the elf should look when
/// determining which direction to move.
#[derive(Debug, Clone, Copy)]
enum Rule {
    North,
    South,
    East,
    West,
}

/// Represents the four rules in the order they should be considered.
#[derive(Debug, Clone)]
struct Rules([Rule; 4]);

impl Rules {
    fn new(rules: [Rule; 4]) -> Self {
        Rules(rules)
    }

    fn inner(&self) -> [Rule; 4] {
        self.0
    }

    fn inner_mut(&mut self) -> &mut [Rule; 4] {
        &mut self.0
    }
}

/// Represents the current status of a proposed move by an elf. When only one
/// elf has propsed to move to a particular Position, use the Move variant. If
/// two or more elves propose to move the the same space, use the Blocked
/// variant.
#[derive(Debug, Clone, Copy)]
enum Proposal {
    Move(usize),
    Blocked,
}

/// Represents the entire program state, the Grove that the elves are spreading
/// out in. Contains a mapping from elf ID to their current position, a set of
/// all the currently occupied positions, a mapping of positions to proposed moves,
/// and the rules for proposing moves in the order they should be considered.
#[derive(Debug, Clone)]
struct Grove {
    elves: HashMap<usize, Position>,
    occupied: HashSet<Position>,
    proposed: HashMap<Position, Proposal>,
    rules: Rules,
}

/// Our parsing function for today. Today's input seemed like it would be more
/// trouble to parse with `nom` that just by iterating over the characters.
impl<'a> From<&'a str> for Grove {
    fn from(input: &str) -> Self {
        // Build up the map of elf ID => elf position.
        let mut elves = HashMap::new();
        for (row_idx, row) in input.lines().enumerate() {
            for (col_idx, glyph) in row.chars().enumerate() {
                if glyph == '.' {
                    continue;
                }
                let position = Position(col_idx as isize, row_idx as isize);
                let elf_id = elves.len();
                elves.insert(elf_id, position);
            }
        }

        // The set of all occupied positions. This is the one we'll use to determine
        // what other elves are in the vicinity of each elf as it proposes its move.
        let occupied = elves.values().copied().collect::<HashSet<_>>();

        // The list of four rules in the initial order
        let rules = Rules([Rule::North, Rule::South, Rule::West, Rule::East]);

        // Maintaining a single list of proposed moves on the Grove
        let proposed = HashMap::with_capacity(occupied.len());

        Grove {
            elves,
            occupied,
            rules,
            proposed,
        }
    }
}

const INPUT: &str = include_str!("../../input/23/input.txt");

/// Parse the input!
fn read() -> Grove {
    Grove::from(INPUT)
}

There definitely seems to be some opportunities to simplify a bit here, but not without spending a bunch more time or compromising readability. I toyed with the idea of some sort of 2-dimensional vector that can expand itself whenever an elf tries to move beyond the borders, but that seemed hard!

Part One - I Just Need Some Space

Surprise, Christmas helpers! It’s me with my crew! Granted, it’s a crew of monkeys and elephants with dubious cross-species communication skills, but we’re here and we’re packing star fruit! We just need a few more and it looks like we can speed up the process by pre-calculating where each elf needs to plant their seed. So, Conway’s Game of Life it is! The major twist is that we need to keep up with each elf individually in case they decide not to move after all. Let’s make that happen.

use std::collections::HashMap;

/// Solve Day 23, Part 1
fn solve(input: &Grove) -> u32 {
    // Get a mutable Grove clone
    let mut grove = input.clone();

    // Advance to the next state ten times
    (0..10).for_each(|_| {
        grove.move_elves();
    });

    // Count the empty spaces and return the count
    grove.count_empty_spaces()
}

impl Grove {
    /// Get the Surroundings of a particular Position in the Grove. If there
    /// are no nearby elves, return None. Otherwise, return Some 3x3 array
    /// where each `true` value indicates the presence of a nearby elf.
    fn get_surroundings(&self, position: Position) -> Option<Surroundings> {
        use Direction::*;

        // Check each of the eight surrounding spaces for the presence
        // of another elf.
        let nw = self.occupied.contains(&position.offset(NorthWest));
        let no = self.occupied.contains(&position.offset(North));
        let ne = self.occupied.contains(&position.offset(NorthEast));
        let ea = self.occupied.contains(&position.offset(East));
        let se = self.occupied.contains(&position.offset(SouthEast));
        let so = self.occupied.contains(&position.offset(South));
        let sw = self.occupied.contains(&position.offset(SouthWest));
        let we = self.occupied.contains(&position.offset(West));
        let cr = true; // Used for the center space

        // If there are no nearby elves, return None
        if !(nw || no || ne || ea || se || so || sw || we) {
            return None;
        }

        // Otherwise, return the Surroundings
        Some(Surroundings::new([
            [nw, no, ne],
            [we, cr, ea],
            [sw, so, se],
        ]))
    }

    /// Gather all the proposals for moving from all the elves at the current
    /// state. Return a map of Positions and the Proposed action for each.
    fn make_proposals(&mut self) {
        // For each elf entry in the mapping of elf => position...
        for (elf, position) in self.elves.iter() {
            // If there are any nearby elves...
            let Some(surroundings) = self.get_surroundings(*position) else { continue; };

            // ...take the first valid proposal for moving the current elf...
            let Some(proposed) = self.rules.try_propose(position, &surroundings) else { continue; };

            // ..and try to add that proposal to the proposal mapping. If
            // this is the first elf proposing to move to the `proposed`
            // position, then add it as a Move proposal. If another elf
            // has already proposed to move to that position, block them
            // both.
            self.proposed
                .entry(proposed)
                .and_modify(|e| *e = Proposal::Blocked)
                .or_insert(Proposal::Move(*elf));
        }
    }

    /// Simulate the elves proposing to move to their new positions then move
    /// the elves where you can. Rotate the rules so that they'll be in the
    /// correct order for the next state change.
    fn move_elves(&mut self) -> bool {
        self.make_proposals();

        // We'll identify and return whether any elves moved during this state change.
        let mut any_moved = false;

        // For each position with a proposal...
        for (position, proposal) in self.proposed.iter() {
            // If the proposal hasn't been blocked, then...
            let Proposal::Move(elf) = proposal else { continue; };

            // Move the elf to the proposed position.
            self.occupied.remove(&self.elves[elf]);
            self.elves.insert(*elf, *position);
            self.occupied.insert(self.elves[elf]);

            // Set the indicator for any elves moved to `true`
            any_moved = true;
        }

        // Rotate the rules order
        self.rules.rotate_left();

        // Clear the proposals
        self.proposed.clear();

        // Return the indicator
        any_moved
    }

    /// Check the current arrangement of elves in the Grove and return two
    /// positions marking the bounds of the rectangle containing all the
    /// elves. The first Position is the top-left corner and the second
    /// Position is the bottom right corner.
    fn bounds(&self) -> (Position, Position) {
        let mut min_x = isize::MAX;
        let mut min_y = isize::MAX;
        let mut max_x = isize::MIN;
        let mut max_y = isize::MIN;

        for (xpos, ypos) in self.occupied.iter().map(|p| p.inner()) {
            min_x = min_x.min(xpos);
            max_x = max_x.max(xpos);
            min_y = min_y.min(ypos);
            max_y = max_y.max(ypos);
        }

        (Position::new(min_x, min_y), Position::new(max_x, max_y))
    }

    /// Count all the empty spaces in the smallest rectangle containing all
    /// the elves.
    fn count_empty_spaces(&self) -> u32 {
        let (min_pos, max_pos) = self.bounds();
        let (min_x, min_y) = min_pos.inner();
        let (max_x, max_y) = max_pos.inner();

        let mut empty_spaces = 0;
        for xpos in min_x..=max_x {
            for ypos in min_y..=max_y {
                let position = Position::new(xpos, ypos);
                if self.occupied.contains(&position) {
                    continue;
                }
                empty_spaces += 1;
            }
        }
        empty_spaces
    }
}

impl Position {
    /// Offset the position by one space in any of the eight directions.
    fn offset(&self, direction: Direction) -> Position {
        let (mut x, mut y) = self.inner();
        match direction {
            Direction::North => y -= 1,
            Direction::East => x += 1,
            Direction::South => y += 1,
            Direction::West => x -= 1,

            Direction::NorthEast => {
                y -= 1;
                x += 1;
            }
            Direction::SouthEast => {
                y += 1;
                x += 1;
            }
            Direction::SouthWest => {
                y += 1;
                x -= 1;
            }
            Direction::NorthWest => {
                y -= 1;
                x -= 1;
            }
        };
        Position::new(x, y)
    }
}

impl Rules {
    /// Rotate the rules such that the current first rule is moved to the
    /// end and the other rules are all moved toward the front of the list.
    fn rotate_left(&mut self) {
        self.inner_mut().rotate_left(1);
    }
}

/// Since I had two structs that were both implementing a `try_propose()` method,
/// I decided to make it a Trait.
trait TryPropose {
    fn try_propose(&self, _: &Position, _: &Surroundings) -> Option<Position>;
}

impl TryPropose for Rule {
    /// Given this Rule and references to a Position and its Surroundings, identify
    /// whether the elf at Position should propose to move and to which Position
    /// he/she should propose to move. Return None if the elf should not propose
    /// to move according to the Rule.
    fn try_propose(&self, position: &Position, surroundings: &Surroundings) -> Option<Position> {
        let [[nw, n, ne], [w, x, e], [sw, s, se]] = surroundings.inner();
        let direction = match self {
            Rule::North if !(nw || n || ne) => Some(Direction::North),
            Rule::South if !(sw || s || se) => Some(Direction::South),
            Rule::East if !(ne || e || se) => Some(Direction::East),
            Rule::West if !(nw || w || sw) => Some(Direction::West),
            _ => None,
        }?;
        Some(position.offset(direction))
    }
}

impl TryPropose for Rules {
    /// Try to get the elf to propose to move by checking each Rule in order.
    /// If the elf can't move for any of the four rules, then return None.
    /// Otherwise, return the first Position that the elf should propose to
    /// move to.
    fn try_propose(&self, position: &Position, surroundings: &Surroundings) -> Option<Position> {
        self.inner()
            .iter()
            .flat_map(|rule| rule.try_propose(position, surroundings))
            .next()
    }
}

Again, there’s probably room for improvement here around checking the surroundings for each elf, there’s probably some efficiency to be gained by not checking all eight spaces for each elf since that means we’re definitely checking some positions multiple times. Maybe something for future enhancement.

Part Two - Get Out of My Bubble

Oh, of course, we need to tell all the elves where they should end up at the end. Well, good news, we don’t actually need to change much to get to the goal.

/// Solve Day 23, Part 2
pub fn solve(input: &Grove) -> u32 {
    // Get a mutable clone of the Grove.
    let mut grove = input.clone();

    // Count the number of rounds it takes for the Grove to
    // reach a state where no elves need to move from one
    // state to the next.
    let mut rounds = 1;
    while grove.move_elves() {
        rounds += 1;
    }

    // Return the number of rounds taken.
    rounds
}

There, now get out there and plant those seeds!

Wrap Up

Full disclosure: after finishing all 25 days, I checked the total runtime and today’s puzzle accounts for almost half of the time it takes to run all 25 days, input parsing and both parts. That feels sloooow, but I’m a bit at a loss for a major breakthrough to get massive speed gains. I need to spend some time thinking about it, but if I’m going to update any of these solutions after the New Year, it’ll probably be this one. Honestly, though, this is one of the things I really enjoy about Advent of Code: finding a solution I’m satisfied with. It’s one thing on a challenge like this one to write code that implements all the rules as written and gets you to the right answer, but it’s another to do so with readable code with optimized performance. It’s sort of that “last 20%” that we often get pressured into avoiding on software projects due to time or budget constraints. It’s nice to have an opportunity to spend a bit of time on the craft of writing code.

Advent of Code 2022 - Day 22

Mon, 26 Dec 2022 00:00:00 +0000

Day 22 - Monkey Map

Find the problem description HERE.

The Input - Misshapen Maps

Buckle up! This one’s a doozy! Actually, parsing the input itself isn’t bad at all, after all, it’s just a square grid with some spaces missing, right? Sure, yeah, that’s true, but that grid represents a map with some special wrapping rules that aren’t particularly consistent from one spot to another. So, it seemed to me that the best way to handle this was to have each space on the map know where you should end up if you move out of that space in any of the four directions. So, it’s sort of a pseudo 2D linked list. So, there’s a bit of post-processing involved in linking up the spaces. This should make actually solving each part of the puzzle easier, though.

use itertools::Itertools;
use std::ops::{Index, IndexMut};

/// Represents a position on the "map", from a top-down perspective. A
/// Position is given as (row, column).
#[derive(Debug, Default, Copy, Clone, PartialEq, Eq)]
struct Position(usize, usize);

/// Indicates the heading of the current movement on the map, from a
/// top-down perspective.
#[derive(Debug, Copy, Clone, PartialEq, Eq)]
enum Heading {
    Up,
    Right,
    Down,
    Left,
}

/// Represents the links from one point on the map to another. This way, each
/// point on the map knows what the heading and position will be for someone
/// who moves in a given direction from that point.
#[derive(Debug, Default, Copy, Clone, PartialEq, Eq)]
struct Links {
    up: Option<(Heading, Position)>,
    right: Option<(Heading, Position)>,
    down: Option<(Heading, Position)>,
    left: Option<(Heading, Position)>,
}

/// Represents a tile on the map
#[derive(Debug, Default, Copy, Clone, PartialEq, Eq)]
enum Tile {
    #[default]
    Void,
    Path(Links),
    Wall,
}

impl Tile {
    /// Sometimes, it's nice to have a function to let us know if the current
    /// Tile is a Tile::Path or not.
    fn is_path(&self) -> bool {
        matches!(self, Tile::Path(_))
    }
}

/// Represents a movement direction, given on the last line of the input file.
#[derive(Debug, Copy, Clone)]
enum Direction {
    TurnLeft,
    TurnRight,
    Forward(u32),
}

/// Represents the tiles on the map given to us by the monkeys, with the added
/// metadata from us added in.
#[derive(Debug, Clone)]
struct MonkeyMap(Vec<Vec<Tile>>);

/// Namespacing for the parsers used in today's puzzle.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::{tag, take_till, take_while},
        character::complete::{alphanumeric0, newline, u32},
        combinator::{map, value},
        multi::{many0, many1, separated_list0},
        sequence::{pair, separated_pair},
        Finish, IResult,
    };

    /// Nom parser for " " -> Tile::Void
    fn void(s: &str) -> IResult<&str, Tile> {
        value(Tile::Void, tag(" "))(s)
    }

    /// Nom parser for "." -> Tile::Path()
    fn passable(s: &str) -> IResult<&str, Tile> {
        value(Tile::Path(Links::default()), tag("."))(s)
    }

    /// Nom parser for "#" -> Tile::Wall
    fn wall(s: &str) -> IResult<&str, Tile> {
        value(Tile::Wall, tag("#"))(s)
    }

    /// Nom parser for all Tile variants
    fn tile(s: &str) -> IResult<&str, Tile> {
        alt((void, passable, wall))(s)
    }

    /// Nom parser for a line of Tiles in the input
    fn tile_line(s: &str) -> IResult<&str, Vec<Tile>> {
        many1(tile)(s)
    }

    /// Nom parser for all the tiles in the input
    fn monkey_map(s: &str) -> IResult<&str, MonkeyMap> {
        map(separated_list0(newline, tile_line), MonkeyMap)(s)
    }

    /// Nom parser for "10" -> Direction::Forward(10)
    fn forward(s: &str) -> IResult<&str, Direction> {
        map(u32, Direction::Forward)(s)
    }

    /// Nom parser for "L" -> Direction::TurnLeft
    fn left(s: &str) -> IResult<&str, Direction> {
        value(Direction::TurnLeft, tag("L"))(s)
    }

    /// Nom parser for "R" -> Direction::TurnRight
    fn right(s: &str) -> IResult<&str, Direction> {
        value(Direction::TurnRight, tag("R"))(s)
    }

    /// Nom parser for all Direction variants
    fn direction(s: &str) -> IResult<&str, Direction> {
        alt((forward, left, right))(s)
    }

    /// Nom parser for the entire list of Directions given in the last line of
    /// the input.
    fn directions(s: &str) -> IResult<&str, Vec<Direction>> {
        many0(direction)(s)
    }

    /// Nom parser for both parts of the input, separated by an empty line.
    fn both_parts(s: &str) -> IResult<&str, (MonkeyMap, Vec<Direction>)> {
        separated_pair(monkey_map, tag("\n\n"), directions)(s)
    }

    /// Entrypoint for parser combinators, parses the input file into a
    /// MonkeyMap and list of Directions.
    pub fn parse(s: &str) -> Result<(MonkeyMap, Vec<Direction>)> {
        let (_, result) = both_parts(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

/// It's convenient to be able to index into the MonkeyMap using a Position,
/// since Position is used to represent a point on the MonkeyMap.
impl Index<Position> for MonkeyMap {
    type Output = Tile;

    fn index(&self, index: Position) -> &Self::Output {
        let Position(row, col) = index;
        &self.0[row][col]
    }
}

/// It's also convenient to be able to access these indices mutably.
impl IndexMut<Position> for MonkeyMap {
    fn index_mut(&mut self, index: Position) -> &mut Self::Output {
        let Position(row, col) = index;
        &mut self.0[row][col]
    }
}

impl MonkeyMap {
    /// Build up the links to other Tiles on each Tile::Path in the MonkeyMap. This
    /// way, we can check a given Tile for the heading and position of the tile in
    /// each of the four cardinal directions.
    fn map_positions(&mut self) {
        let rows = self.0.len();

        // Iterating over the indices keeps borrow checker wrangling to a minimum
        // here. We need to get the number of columns individually for each row,
        // since each row has a variable number of columns. The input doesn't have
        // spaces at the ends of lines where the map doesn't span to the end of the
        // line.
        for row in 0..rows {
            let cols = self.0.get(row).map(|v| v.len()).unwrap_or_default();
            for col in 0..cols {
                if let Tile::Path(mut links) = self.0[row][col] {
                    let position = Position(row, col);
                    links.up = self.find_next_up(position);
                    links.right = self.find_next_right(position);
                    links.down = self.find_next_down(position);
                    links.left = self.find_next_left(position);
                    self[position] = Tile::Path(links);
                }
            }
        }
    }

    /// From a given position, identify the Heading/Position of the Tile that can
    /// be achieved by moving up from the current position. Accounts for wrapping
    /// around the map when moving up into an unmarked space.
    fn find_next_up(&self, position: Position) -> Option<(Heading, Position)> {
        let Position(row, col) = position;
        let inner_iter = self.0.iter();

        // This is a bit of a gnarly iterator chain, but the ultimate outcome is that
        // it produces an iterator that starts at the current position and moves along
        // the current column by row, in reverse, and returns the first position found
        // that isn't a Tile::Void, which provides the wrapping functionality. This
        // is probably the gnarliest of the four functions, since it requires iterating
        // by column and in reverse. The rest of the `find_next_*()` functions are
        // all variations on this one.
        let (found_row, found_tile) = inner_iter
            .enumerate()
            .rev()
            .map(|(row_idx, row)| (row_idx, row.get(col).unwrap_or(&Tile::Void)))
            .cycle()
            .skip(self.0.len() - row)
            .find(|(_, tile)| !matches!(tile, Tile::Void))?;
        if found_tile.is_path() {
            return Some((Heading::Up, Position(found_row, col)));
        }
        None
    }

    /// From a given position, identify the Heading/Position of the Tile that can
    /// be achieved by moving down from the current position. Accounts for wrapping
    /// around the map when moving up into an unmarked space.
    fn find_next_down(&self, position: Position) -> Option<(Heading, Position)> {
        let Position(row, col) = position;
        let inner_iter = self.0.iter();
        let (found_row, found_tile) = inner_iter
            .enumerate()
            .map(|(row_idx, row)| (row_idx, row.get(col).unwrap_or(&Tile::Void)))
            .cycle()
            .skip(row + 1)
            .find(|(_, tile)| **tile != Tile::Void)?;
        if found_tile.is_path() {
            return Some((Heading::Down, Position(found_row, col)));
        }
        None
    }

    /// From a given position, identify the Heading/Position of the Tile that can
    /// be achieved by moving left from the current position. Accounts for wrapping
    /// around the map when moving up into an unmarked space.
    fn find_next_left(&self, position: Position) -> Option<(Heading, Position)> {
        let Position(row, col) = position;
        let row_of_tiles = self.0.get(row)?;
        let (found_col, found_tile) = row_of_tiles
            .iter()
            .enumerate()
            .rev()
            .cycle()
            .skip(row_of_tiles.len() - col)
            .find(|(_, tile)| **tile != Tile::Void)?;
        if found_tile.is_path() {
            return Some((Heading::Left, Position(row, found_col)));
        }
        None
    }

    fn find_next_right(&self, position: Position) -> Option<(Heading, Position)> {
        let Position(row, col) = position;
        let row_of_tiles = self.0.get(row)?;

        // And this one is probably the least gnarly. Which obviously means it was
        // the one I wrote last. I really should have written these in reverse,
        // because writing the "up" iterator chain as a PITA and I could have
        // used this one as a template. Ah, well.
        let (found_col, found_tile) = row_of_tiles
            .iter()
            .enumerate()
            .cycle()
            .skip(col + 1)
            .find(|(_, tile)| **tile != Tile::Void)?;
        if found_tile.is_path() {
            return Some((Heading::Right, Position(row, found_col)));
        }
        None
    }
}

const INPUT: &str = include_str!("../../input/22/input.txt");

/// Parse that input!
fn read() -> (MonkeyMap, Vec<Direction>) {
    let (mut map, directions) = parser::parse(INPUT).unwrap();
    map.map_positions();
    (map, directions)
}

That’s a neat trick with the iterators for identifying the next space in any given direction, accounting for wrapping, right? I like it, anyway.

Part One - Wrapping and Mapping

Wait, so we’re friendly with the monkeys, now? Ok, seems like elephants make better ambassadors than I thought, although they may just feel bad for us after out pathetic display when they took our stuff. Or, maybe we impressed them with our math prowess. Either way, it beats the alternative. Plus, they’ve given us some notes they took down about the password to get into the star fruit grove. It’s a bit disconcerting that the monkeys are watching the elves put in the password and taking notes, but it’s working in our favor, so let’s not think too deeply about that right now.

/// Solve Day 22, Part 1
fn solve(input: &(MonkeyMap, Vec<Direction>)) -> u32 {
    // This bit is just so I can convert the reference to the input into a
    // mutable map. I pass in the input as a reference because it keeps me from
    // accidentally mutating it in Part 1 and spending hours wondering why
    // my solution for Part 2 doesn't work on the input I forgot I had mutated.
    let (monkey_map, directions) = input;
    let mut board = monkey_map.clone();

    // Start at the first path Tile on the first row, facing right
    let Some(start_pos) = board.first_path_position() else { 
        panic!("Cannot find start position!"); 
    };
    let mut walker = Walker::new(start_pos);

    // Follow each direction
    directions
        .iter()
        .for_each(|direction| walker.follow(&board, *direction));

    // Let the walker calculate its own score and return it
    walker.score()
}

impl MonkeyMap {
    /// Finds the position of the first Tile::Path in the MonkeyMap,
    /// in reading order (left to right, top to bottom), if there is
    /// one.
    fn first_path_position(&self) -> Option<Position> {
        let first_row = self.0.first()?;
        let first_col = first_row
            .iter()
            .position(|tile| matches!(tile, Tile::Path(_)))?;
        Some(Position(0, first_col))
    }
}

impl Tile {
    /// Get the links associated with the Tile. If it's a Tile::Void
    /// or Tile::Wall, the default is a Links with no links filled in.
    /// That doesn't actually come up much, though.
    fn links(&self) -> Links {
        match self {
            Tile::Path(links) => *links,
            _ => Links::default(),
        }
    }
}

/// Represents a "walker" walking the path on the MonkeyMap.
#[derive(Debug)]
struct Walker(Heading, Position);

impl Walker {
    fn new(position: Position) -> Self {
        Walker(Heading::Right, position)
    }

    /// Lets the Walker calculate it's own score according to the puzzle description.
    fn score(&self) -> u32 {
        let Walker(heading, position) = self;
        let Position(row, col) = position;
        let heading_mod = match heading {
            Heading::Right => 0,
            Heading::Down => 1,
            Heading::Left => 2,
            Heading::Up => 3,
        };
        ((*row as u32 + 1) * 1000) + ((*col as u32 + 1) * 4) + heading_mod
    }

    /// Given a direction and a reference to the map, attempt to follow the
    /// direction by moving or turning the Walker.
    fn follow(&mut self, map: &MonkeyMap, direction: Direction) {
        let Walker(heading, position) = self;
        let tile = map[*position];
        let Tile::Path(links) = tile else { return; };

        use Direction::*;
        use Heading::*;
        match (heading, direction) {
            // Turning is easy, just match and update the Walker with the new heading
            (Up, TurnLeft) => *self = Walker(Left, *position),
            (Up, TurnRight) => *self = Walker(Right, *position),

            (Right, TurnLeft) => *self = Walker(Up, *position),
            (Right, TurnRight) => *self = Walker(Down, *position),

            (Down, TurnLeft) => *self = Walker(Right, *position),
            (Down, TurnRight) => *self = Walker(Left, *position),

            (Left, TurnLeft) => *self = Walker(Down, *position),
            (Left, TurnRight) => *self = Walker(Up, *position),

            // Moving forward is a bit tougher, but not too serious.
            (heading, Forward(n)) => {
                // As many times as we're suppose to move forward...
                for _ in 0..n {
                    // Unpack the walker again since we're going to modify it
                    // directly in subsequent loops.
                    let Walker(heading, position) = self;

                    // Here's where having the Links stored on the Tiles comes in
                    // handy. We can just query the links on the current Tile for
                    // the heading and position we should be at if we move in the
                    // indicated direction from the current Tile.
                    let mut links = map[*position].links();
                    let link = match heading {
                        Up => links.up,
                        Right => links.right,
                        Down => links.down,
                        Left => links.left,
                    };

                    // If there's no link in the indicated direction, just stop.
                    // Otherwise, update the Walker and keep going.
                    let Some((heading, position)) = link else { break; };
                    *self = Walker(heading, position)
                }
            }
        };
    }
}

It’s a bit verbose, and there’s a lot of comments there, but all told that’s a pretty straightforward implementation of direction following. We don’t even need to think about the weird map shape anymore since the map links make it a non-issue.

Part Two - Let’s Wrap This Up

You know, I thought that map shape as a bit suspicious, but the whole rectangular nature of ASCII characters threw me off. Of course it’s really a cube, why wouldn’t it be!? To be fair to the monkeys, they probably said something about that, but I don’t speak monkey and the elephants have proven to be a bit unreliable in that regard. The good news here is that our strategy of storing links on each map tile sets us up well for handling part two. The bad news is that it’s going to be super tedious…

/// Solve Day 22, Part 2
fn solve(input: &(MonkeyMap, Vec<Direction>)) -> u32 {
    let (board, directions) = input;
    let mut board = board.clone();
    board.wrap(); // This is the difference!
    let Some(start_pos) = board.first_path_position() else { 
        panic!("Cannot find start position!"); 
    };
    let mut walker = Walker::new(start_pos);
    directions
        .iter()
        .for_each(|direction| walker.follow(&board, *direction));
    walker.score()
}

impl MonkeyMap {
    /// My map looks like this, where the pairs of letters indicate pairs of edges
    /// that line up to form the cube if this shape were folded.
    ///
    ///            _______ _______
    ///           |   A   |   B   |
    ///           |C      |      D|
    ///           |_______|___F___|
    ///           |       |
    ///           |E     F|
    ///    _______|_______|
    ///   |   E   |       |
    ///   |C      |      D|
    ///   |_______|___G___|
    ///   |       |
    ///   |A     G|
    ///   |___B___|
    ///
    /// Yours probably doesn't. This function re-maps the connections on the linkss
    /// on the outside edges to the correct matching edge. The hard part is making
    /// sure you match up the right edges in the right order. I recommend cutting
    /// out the shape of your map on a sheet of paper, folding it into a cube, and
    /// using that cube to determine how to match up the sides. This was an incredibly
    /// tedious bit of code to write because the various joins between the open face
    /// pairs all had their own bits of uniqueness that prevented me from doing this
    /// in a loop. So, each pair of faces is being joined manually.
    fn wrap(&mut self) {
        let inner = &self.0;

        // Match up the (A) sides. All the faces are joined this way, where I
        // iterate along the positions from the matching faces in the order that
        // they match up and modify their links as needed to have each edge direct
        // the Walker to the corresponding Tile on the other face. This was made
        // even more tedious by the fact that this approach is completely different
        // that the one I'd need to take to do this for the example input, since
        // the example map is shaped differently from my input.
        let side1 = (50..100).map(|col| Position(0, col));
        let side2 = (150..200).map(|row| Position(row, 0));
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.up = if self[p2].is_path() {
                    Some((Heading::Right, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.left = if self[p1].is_path() {
                    Some((Heading::Down, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (B) sides.
        let side1 = (100..150).map(|col| Position(0, col));
        let side2 = (0..50).map(|col| Position(199, col));
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.up = if self[p2].is_path() {
                    Some((Heading::Up, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.down = if self[p1].is_path() {
                    Some((Heading::Down, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (C) sides.
        let side1 = (0..50).map(|row| Position(row, 50));
        let side2 = (100..150).map(|row| Position(row, 0)).rev();
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.left = if self[p2].is_path() {
                    Some((Heading::Right, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.left = if self[p1].is_path() {
                    Some((Heading::Right, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (D) sides.
        let side1 = (0..50).map(|row| Position(row, 149));
        let side2 = (100..150).map(|row| Position(row, 99)).rev();
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.right = if self[p2].is_path() {
                    Some((Heading::Left, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.right = if self[p1].is_path() {
                    Some((Heading::Left, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (E) sides.
        let side1 = (50..100).map(|row| Position(row, 50));
        let side2 = (0..50).map(|col| Position(100, col));
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.left = if self[p2].is_path() {
                    Some((Heading::Down, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.up = if self[p1].is_path() {
                    Some((Heading::Right, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (F) sides.
        let side1 = (100..150).map(|col| Position(49, col));
        let side2 = (50..100).map(|row| Position(row, 99));
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.down = if self[p2].is_path() {
                    Some((Heading::Left, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.right = if self[p1].is_path() {
                    Some((Heading::Up, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // Match up the (G) sides.
        let side1 = (50..100).map(|col| Position(149, col));
        let side2 = (150..200).map(|row| Position(row, 49));
        for (p1, p2) in std::iter::zip(side1, side2) {
            if self[p1].is_path() {
                let mut links = self[p1].links();
                links.down = if self[p2].is_path() {
                    Some((Heading::Left, p2))
                } else {
                    None
                };
                self[p1] = Tile::Path(links);
            }

            if self[p2].is_path() {
                let mut links = self[p2].links();
                links.right = if self[p1].is_path() {
                    Some((Heading::Up, p1))
                } else {
                    None
                };
                self[p2] = Tile::Path(links);
            }
        }

        // And that's that! Seven slightly different edge-to-edge joins! I can't
        // tell you how many small "typo" bugs I made in these seven blocks. The
        // good news is that once the edges are forwarding correctly, walking the
        // "cube" is exactly the same as walking the map in part one.
    }
}

Why yes, that is a lot of code! Why do you ask?

Wrap Up

This was the most fun, interesting, and frustrating puzzle so far! Honestly, there’s something in me that rebels at the idea that my solution definitely won’t work for other people’s inputs. Given that the example is also a different shape from my input, every time I considered trying to test my approach on the example, I realized that it would be completely useless because I’d have to write a totally different implementation for the example shape. There’s probably some way I could have abstracted the process enough to cut down on the repetition, but this late in the season, my brain refused to put it together. That said, this was the first puzzle this year that forced me to get crafty with real world materials in order to properly reason about what I was doing, which is really quite charming. So, I give this puzzle a final grade of A with a snarky note written at the top of the page. That’ll show…somebody. I guess.

Advent of Code 2022 - Day 21

Sun, 25 Dec 2022 00:00:00 +0000

Day 21 - Monkey Math

Find the problem description HERE.

The Input - Weird Expressions

Input parsing is the real heavy lift of today’s puzzle. Now, if we were running Python or Julia or some such, we could use eval() or similar on the inputs until we get an answer, but where’s the fun in that? Instead, let’s simulate a context-free grammar and parse these monkey math expressions into something that looks a bit like an R environment. Could probably have actually gone all the way to an abstract syntax tree, but nesting structs is a bit of a pain in Rust. Instead, we’ll store each expression in a HashMap under the name of the monkey left of the assignment operator, with an Expression as the value. It’s not so much that there’s an excessive amount of parsing today as the data structures we’re using are pretty specific.

use anyhow::{bail, Error};
use std::collections::HashMap;

/// Represents the names of each monkey. I originally wanted to use
/// string references as the monkey labels, but that causes borrow
/// checker issues with mutating the Environment (defined below),
/// so I'm using a small, cheap array of characters instead.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
struct Label([char; 4]);

/// Try to convert a string slice to a Label. Only works for string
/// slices with exactly four characters.
impl TryFrom<&str> for Label {
    type Error = Error;

    fn try_from(value: &str) -> Result<Self, Self::Error> {
        if value.len() != 4 {
            bail!("Can only convert a 4-character string to Label")
        }
        let mut out = ['\0'; 4];
        for (idx, ch) in value.chars().enumerate() {
            out[idx] = ch;
        }
        Ok(Label(out))
    }
}

/// Represents a Value being passed from monkey to monkey. Either a reference
/// to another monkey, or a raw number.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
enum Value {
    Ref(Label),  // reference
    Raw(i128),   // raw number
}

/// Converts a string slice into a Value::Ref. Just convenient to have.
impl TryFrom<&str> for Value {
    type Error = Error;

    fn try_from(value: &str) -> Result<Self, Self::Error> {
        Ok(Value::Ref(Label::try_from(value)?))
    }
}

/// Represents one of the mathematical expressions being evaluated by a
/// monkey. Every monkey is evaluating an expression, even if it's just
/// to report a value.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
enum Expression {
    Add(Value, Value),
    Sub(Value, Value),
    Mul(Value, Value),
    Div(Value, Value),
    Val(Value),
}

/// Represents the environment in which monkey math is being evaluated. Keeps
/// track of each variable (monkey) and their current assigned Expression.
#[derive(Debug, Clone)]
struct Environment(HashMap<Label, Expression>);

/// Wraps the parsing functions for today's input.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::tag,
        character::complete::{alpha1, i128, newline},
        combinator::{map, map_res, verify},
        multi::separated_list0,
        sequence::separated_pair,
        Finish, IResult,
    };

    /// Nom parser for "humn" -> Label(['h', 'u', 'm', 'n'])
    fn label(s: &str) -> IResult<&str, Label> {
        map_res(alpha1, Label::try_from)(s)
    }

    /// Nom parser for "humn" -> Value::Ref(Label(['h', 'u', 'm', 'n']))
    fn value_ref(s: &str) -> IResult<&str, Value> {
        map(label, Value::Ref)(s)
    }

    /// Nom parser for "15" -> Value::Raw(15)
    fn value_raw(s: &str) -> IResult<&str, Value> {
        map(i128, Value::Raw)(s)
    }

    /// Nom parser for monkey addition expressions
    fn expr_add(s: &str) -> IResult<&str, (Label, Expression)> {
        let (s, lbl) = label(s)?;
        let (s, _) = tag(": ")(s)?;
        let (s, (v1, v2)) = separated_pair(value_ref, tag(" + "), value_ref)(s)?;
        Ok((s, (lbl, Expression::Add(v1, v2))))
    }

    /// Nom parser for monkey subtraction expressions
    fn expr_sub(s: &str) -> IResult<&str, (Label, Expression)> {
        let (s, lbl) = label(s)?;
        let (s, _) = tag(": ")(s)?;
        let (s, (v1, v2)) = separated_pair(value_ref, tag(" - "), value_ref)(s)?;
        Ok((s, (lbl, Expression::Sub(v1, v2))))
    }

    /// Nom parser for monkey multiplication expressions
    fn expr_mul(s: &str) -> IResult<&str, (Label, Expression)> {
        let (s, lbl) = label(s)?;
        let (s, _) = tag(": ")(s)?;
        let (s, (v1, v2)) = separated_pair(value_ref, tag(" * "), value_ref)(s)?;
        Ok((s, (lbl, Expression::Mul(v1, v2))))
    }

    /// Nom parser for monkey division expressions
    fn div_expr(s: &str) -> IResult<&str, (Label, Expression)> {
        let (s, lbl) = label(s)?;
        let (s, _) = tag(": ")(s)?;
        let (s, (v1, v2)) = separated_pair(value_ref, tag(" / "), value_ref)(s)?;
        Ok((s, (lbl, Expression::Div(v1, v2))))
    }

    /// Nom parser for monkey value expressions
    fn val_expr(s: &str) -> IResult<&str, (Label, Expression)> {
        let (s, lbl) = label(s)?;
        let (s, _) = tag(": ")(s)?;
        let (s, value) = value_raw(s)?;
        Ok((s, (lbl, Expression::Val(value))))
    }

    /// Nom parser for all variants of an Expression
    fn expression(s: &str) -> IResult<&str, (Label, Expression)> {
        alt((val_expr, expr_add, expr_sub, expr_mul, div_expr))(s)
    }

    /// Nom parser for a newline-separated list of Expressions
    fn expressions(s: &str) -> IResult<&str, HashMap<Label, Expression>> {
        let (s, exprs) = separated_list0(newline, expression)(s)?;
        let exprs = exprs.into_iter().collect::<HashMap<_, _>>();
        Ok((s, exprs))
    }

    /// Parses the input file into an Environment
    fn parse(s: &str) -> Result<Environment> {
        let (_, result) = expressions(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(Environment(result))
    }
}

const INPUT: &str = include_str!("../../input/21/input.txt");

/// Parse that input!
fn read() -> Environment {
    parser::parse(INPUT).unwrap()
}

My first pass through today’s puzzle kept string slices that referred to the input as the Environment keys, which worked fine for part one. In part two (spoiler alert), I ended up wanting to modify the Environment, which created a bunch of lifetime pain. I probably could have gotten around that with a Cow<&str>, but the little array labels worked just as well.

Part One - King Kalculus

Oh, goodness, it’s the monkeys again! Well, at least this time we have elephants to translate for us so we can communicate with the monkeys instead of simply screaming at them in frustration until we black out. Ah, good times… Anyway, looks like this time the monkeys are trying to be helpful. Well, really, more like “trying”, since it’s entirely possible they could just point us in the right direction without this riddle-solving business. Good thing we like riddles…

/// Solve Day 21, Part 1
fn solve(input: &Environment) -> i128 {
    let root = Value::try_from("root").unwrap();
    root.eval(input).unwrap()
}

/// Fetch an Expression from the Environment by Label
impl Environment {
    fn resolve(&self, var: &Label) -> Option<Expression> {
        self.0.get(var).copied()
    }
}

/// Trait for evaluating an Expression in an Environment
trait Eval {
    fn eval(&self, env: &Environment) -> Option<i128>;
}

impl Eval for Value {
    /// Recursively evaluate the Value until a Value::Raw can be returned
    fn eval(&self, env: &Environment) -> Option<i128> {
        match self {
            Value::Ref(var) => env.resolve(var).and_then(|v| v.eval(env)),
            Value::Raw(val) => Some(*val),
        }
    }
}

impl Eval for Expression {
    /// Recursively evaluate the Value until a Value::Raw can be returned
    fn eval(&self, env: &Environment) -> Option<i128> {
        // Perform operations based on the type of Expression
        match self {
            Expression::Add(v1, v2) => Some(v1.eval(env)? + v2.eval(env)?),
            Expression::Sub(v1, v2) => Some(v1.eval(env)? - v2.eval(env)?),
            Expression::Mul(v1, v2) => Some(v1.eval(env)? * v2.eval(env)?),
            Expression::Div(v1, v2) => Some(v1.eval(env)? / v2.eval(env)?),
            Expression::Val(value) => value.eval(env),
        }
    }
}

Ok, that was a really big number that “root” monkey just added up entirely in his head. I’m starting to wonder whether this whole “translation” thing is entirely necessary. I bet that monkey can speak English, too. They’re probably just humoring the elephants: “Oh, yes, your pronunciation is just fine.” they say.

Part Two - Mass Communication Mishap

Except, as it turns out, the elephants’ pronunciation of monkey isn’t actually all that good. Or maybe it’s our ability to understand elephant. Either way, it looks like we’re participating in this game. We’ll need to figure out what number to shout to get the “root” monkey to have two equal numbers to compare. The good news is that the number of monkeys waiting with bated breath to hear our number is actually pretty small, so only one side of the comparison changes depending on what we shout. This cuts down on the potential complexity a lot.

fn solve(input: &Environment) -> i128 {
    use Expression::*;
    use Value::*;

    // Eject the assignment to the "humn" variable from the environment.
    // We'll be calculating that.
    let mut env = input.clone();
    let humn_lbl = Label::try_from("humn").unwrap();
    env.remove(&humn_lbl);

    // Since the "root" monkey is supposed to check two numbers for equality,
    // let's get the two variables that the boss monkey will be checking and
    // determine what we get if we try to evaluate them.
    let root_lbl = Label::try_from("root").unwrap();
    let Add(left, right) = env.resolve(&root_lbl).unwrap() else { panic!("No root monkey!"); };

    // The PartialEval trait attempts to evaluate the calling expression and
    // updates each variable in the environment that can be evalutated along
    // the way. From this point forward, every variable in the environment
    // that doesn't depend on "humn" will be a raw value instead of an expression
    // containing references.
    let left_val = left.partial_eval(&mut env);
    let right_val = right.partial_eval(&mut env);

    // Turns out, from examining the input, there's only one path that depends
    // on the "humn" variable. This means that one of the two variables being
    // checked will be constant and the other will depend on the value of
    // "humn". So. let's check what we got from evaluating the left and right
    // variables and see which one returned an actual value. That will be the
    // value we start adjusting moving forward. The other variable value will
    // represent the formula we need to solve.
    let (mut carry, mut next_op) = match (left_val, right_val) {
        (lhs, Val(Raw(val))) => (val, Some(lhs)),
        (Val(Raw(val)), rhs) => (val, Some(rhs)),
        _ => unreachable!(),
    };

    // Since we know that both values checked by the "root" monkey must be equal,
    // then we know enough to start solving each expression from `next_op` all
    // the way to the value of "humn". For example, say we had the following
    // set of relationships:
    //
    // - root =  5 == abcd (5)
    // - abcd = 10 - efgh ->  5 = 10 - efgh -> efgh = 10 - 5 -> efgh =  5
    // - efgh = 60 / ijkl ->  5 = 60 / ijkl -> ijkl = 60 / 5 -> ijkl = 12
    // - ijkl =  3 * humn -> 12 =  3 * humn -> humn = 12 / 3 -> humn =  4
    //
    // Thus, we can calculate the value of "humn" by substituting values into
    // formulae and solving by rearrangement one formula at a time until we
    // find the value of "humn".
    while let Some(expr) = next_op {
        // Rearrange the expressions based on the value we're carrying forward and
        // the type of operation being performed. There's a lot of "unreachable"
        // points along the way that are possible because we know that every
        // variable that doesn't depend on "humn" has already been fully evaluated.
        (carry, next_op) = match expr {
            Add(lhs, rhs) => match (lhs, rhs) {
                (Ref(lhs), Raw(val)) => (carry - val, env.resolve(&lhs)),
                (Raw(val), Ref(rhs)) => (carry - val, env.resolve(&rhs)),
                (_, _) => unreachable!(),
            },
            Sub(lhs, rhs) => match (lhs, rhs) {
                (Ref(lhs), Raw(val)) => (val + carry, env.resolve(&lhs)),
                (Raw(val), Ref(rhs)) => (val - carry, env.resolve(&rhs)),
                (_, _) => unreachable!(),
            },
            Mul(lhs, rhs) => match (lhs, rhs) {
                (Ref(lhs), Raw(val)) => (carry / val, env.resolve(&lhs)),
                (Raw(val), Ref(rhs)) => (carry / val, env.resolve(&rhs)),
                (_, _) => unreachable!(),
            },
            Div(lhs, rhs) => match (lhs, rhs) {
                (Ref(lhs), Raw(val)) => (val * carry, env.resolve(&lhs)),
                (Raw(val), Ref(rhs)) => (val / carry, env.resolve(&rhs)),
                (_, _) => unreachable!(),
            },
            Val(_) => unreachable!(),
        };
    }

    carry.into()
}

/// Remove an expression from the Environment based on Label
impl Environment {
    fn remove(&mut self, label: &Label) -> Option<Expression> {
        self.0.remove(label)
    }
}

/// This trait is used to evaluate Expressions in an Environment, updating
/// the Environment whenever a variable is evaluated. Going forward, the
/// Environment will have variables as fully evaluated as possible upon
/// which the expression that calls PartialEval depends.
trait PartialEval {
    fn partial_eval(&self, env: &mut Environment) -> Expression;
}

impl PartialEval for Value {
    fn partial_eval(&self, env: &mut Environment) -> Expression {
        use Expression::*;
        use Value::*;

        match self {
            // This is where the magic happens. Every time a reference is
            // successfully evaluated, update the Environment with its new
            // value.
            Ref(var) => {
                let Some(expr) = env.resolve(var) else { return Val(*self); };
                let eval = expr.partial_eval(env);
                env.0.insert(*var, eval);
                eval
            }
            _ => Val(*self),
        }
    }
}

impl PartialEval for Expression {
    fn partial_eval(&self, env: &mut Environment) -> Expression {
        use Expression::*;
        use Value::*;

        // For each type of expression, if it can be fully evaluated, do so. If
        // only one side can be evaluated, evaluate that one and retain the other
        // as-is.
        match self {
            Add(v1, v2) => match (v1.partial_eval(env), v2.partial_eval(env)) {
                (Val(Raw(lhs)), Val(Raw(rhs))) => Val(Raw(lhs + rhs)),
                (_, Val(Raw(rhs))) => Add(*v1, Raw(rhs)),
                (Val(Raw(lhs)), _) => Add(Raw(lhs), *v2),
                (_, _) => *self,
            },
            Sub(v1, v2) => match (v1.partial_eval(env), v2.partial_eval(env)) {
                (Val(Raw(lhs)), Val(Raw(rhs))) => Val(Raw(lhs - rhs)),
                (_, Val(Raw(rhs))) => Sub(*v1, Raw(rhs)),
                (Val(Raw(lhs)), _) => Sub(Raw(lhs), *v2),
                (_, _) => *self,
            },
            Mul(v1, v2) => match (v1.partial_eval(env), v2.partial_eval(env)) {
                (Val(Raw(lhs)), Val(Raw(rhs))) => Val(Raw(lhs * rhs)),
                (_, Val(Raw(rhs))) => Mul(*v1, Raw(rhs)),
                (Val(Raw(lhs)), _) => Mul(Raw(lhs), *v2),
                (_, _) => *self,
            },
            Div(v1, v2) => match (v1.partial_eval(env), v2.partial_eval(env)) {
                (Val(Raw(lhs)), Val(Raw(rhs))) => Val(Raw(lhs / rhs)),
                (_, Val(Raw(rhs))) => Div(*v1, Raw(rhs)),
                (Val(Raw(lhs)), _) => Div(Raw(lhs), *v2),
                (_, _) => *self,
            },
            // Obviously, a value has fewer options
            Expression::Val(value) => value.partial_eval(env),
        }
    }
}

Lots of match statements in that, but it all boils down to relatively simple math. I won’t reveal how long it took me to realize it was relatively simple math, but once I got that part, the rest sort of fell into place.

Wrap Up

Today was an incredibly fun puzzle. I really enjoyed working out how to represent today’s problem space. The recursive evaluation for part one was really straightforward, and so was the step-wise “solve for x” approach to part two once I realized that that would work. I suspect this was actually the intended solution for today, because once you realize it, it’s just so “obvious” that it should work this way. Implementing it in code brought a whole host of considerations, but in the end, it was figuring out how to translate a logical, understandable process into code. Something about that just scratches an itch for me, and I honestly found today’s puzzle to be pretty calming, overall.

Advent of Code 2022 - Day 20

Sat, 24 Dec 2022 00:00:00 +0000

Day 20 - Grove Positioning System

Find the problem description HERE.

The Input - Just Some Numbers

Our input file for today’s puzzle is a list of numbers. Some of them are even negative. Fancy, right?

const INPUT: &str = include_str!("../../input/20/input.txt");

fn read() -> Vec<i64> {
    INPUT.lines().flat_map(|l| l.parse::<i64>()).collect()
}

Part One - Make Mine a Double (Linked List)

Now that we’re all done collecting obsidian, we need to calculate the coordinates of the star fruit grove. This still sounds suspiciously like what we’d need to do to effectively use a nether portal, so I assume that’s the point of this exercise. I mean, surely we’re not about to just walk, right? At least we can count on the elves for interesting encryption algorithms. Not good encryption algorithms mind you, but that’s working in our favor today. The code below may look a bit odd, but the key insight is that we can simulate a doubly-linked list using vectors, which is made easier because we aren’t actually adding anything, just moving things around.

use std::collections::HashMap;
use std::ops::{Add, AddAssign, Index, IndexMut};

/// Solve Day 20, Part 1
fn solve(input: &[i64]) -> i64 {
    // Make a decryptor!
    let mut decryptor = MixingDecryptor::from(input.clone());
    decryptor.mix();

    // Just like that!
    decryptor.grove_coordinates_sum()
}

/// Really just a convenient struct for bundling together the three vectors
/// we'll use to solve this puzzle. Who needs an actual linked list when you
/// can just simulate one! The three vectors here will serve as a
/// pseudo-doubly-linked-list, with the values in `nodes`, the pointers to
/// next values in `forward_links`, and the pointers ot previous values
/// in `backward_links`.
#[derive(Debug)]
struct MixingDecryptor {
    nodes: Vec<i64>,
    forward_links: Vec<usize>,
    backward_links: Vec<usize>,
}

impl From<Vec<i64>> for MixingDecryptor {
    fn from(nodes: Vec<i64>) -> Self {
        // The forward links are the indices of the nodes that come after the
        // node at the same index as the link. So, `forward_links[node[0]]`
        // in the unmixed list would be `1`.
        let forward_links: Vec<_> = (1..nodes.len())
            .into_iter()
            .chain(std::iter::once(0))
            .collect();

        // The backward links are the indices of the nodes that come before the
        // node at the same index as the link.
        let backward_links: Vec<_> = std::iter::once(nodes.len() - 1)
            .chain(0..(nodes.len() - 1))
            .collect();

        MixingDecryptor {
            nodes,
            forward_links,
            backward_links,
        }
    }
}

impl MixingDecryptor {
    /// Mix up that list!
    fn mix(&mut self) {
        let Self {
            nodes,
            forward_links,
            backward_links,
        } = self;
        for (moved_node_idx, moved_node) in nodes.iter().copied().enumerate() {
            // If the value of the node is zero, don't move anything.
            if moved_node == 0 {
                continue;
            }

            // We calculate the number of skips such that we never
            // wrap fully around the list of nodes. We do this by taking
            // the absolute value of the node mod the length of the list
            // minus one. Why minus one? Because we don't count the node
            // we're moving.
            let skips = (moved_node.unsigned_abs() as usize) % (nodes.len() - 1);

            // Find the index of the node we'll displace by following the links from
            // the current node a number of times indicated by the value of the node.
            // Follow forward links for positive numbers and backward links for
            // negative numbers.
            let mut displaced_node_idx = moved_node_idx;
            for _ in (0..skips) {
                if moved_node > 0 {
                    displaced_node_idx = forward_links[displaced_node_idx];
                }
                if moved_node < 0 {
                    displaced_node_idx = backward_links[displaced_node_idx];
                }
            }

            // Move backwards one more time if the value of the node is negative,
            // since the displaced node is always displaced to the left.
            if moved_node < 0 {
                displaced_node_idx = backward_links[displaced_node_idx];
            }

            // Get the indices of other nodes we'll need to adjust links for
            let moved_node_next = forward_links[moved_node_idx];
            let moved_node_prev = backward_links[moved_node_idx];
            let displaced_node_next = forward_links[displaced_node_idx];

            // Close the gap left by the moved node
            forward_links[moved_node_prev] = moved_node_next;
            backward_links[moved_node_next] = moved_node_prev;

            // Insert the moved node after the displaced node
            forward_links[moved_node_idx] = displaced_node_next;
            backward_links[moved_node_idx] = displaced_node_idx;

            // Update the links for the displaced node
            forward_links[displaced_node_idx] = moved_node_idx;
            backward_links[displaced_node_next] = moved_node_idx;
        }
    }

    /// Get the index of the zero value.
    fn find_zero_index(&self) -> usize {
        // This is safe because the puzzle tells us that there's a zero in the
        // input. Otherwise, unwrapping here would be a bad idea.
        self.nodes.iter().position(|x| *x == 0).unwrap()
    }

    /// Find and sum the 1000th, 2000th, and 3000th values in order starting
    /// from the zero value, wrapping around the list as necessary.
    fn grove_coordinates_sum(&self) -> i64 {
        let mut current_index = self.find_zero_index();
        let mut total = 0;

        // Similar to how we mixed the lists, we can just follow links through
        // the `forward_links` vector to move forward in the list.
        for positions_after in 1..=3000 {
            current_index = self.forward_links[current_index];
            if positions_after % 1000 == 0 {
                total += self.nodes[current_index];
            }
        }
        total
    }
}

There’s a good amount of code here, but it mostly just amounts to taking the target number out of the list, closing up the hole it left behind, and inserting it between the two numbers where it belongs.

Part Two - Sir Mix-A-Lot

Oh, of course! We forgot the random large prime number! Happens all the time. I’m actually more impressed that we apparently remember this number correctly. I guess all this problem-solving has really paid off in mental acuity, or something like that. Oh, and we need to do way more mixing, because of course we do!

/// Solve Day 20, Part 2
///
/// No real changes here, other than multiplying each value by some hefty
/// prime-looking number and mixing the list ten times. Just call me
/// Sir Mix-A-Lot.
fn solve(input: &[i64]) -> i64 {
    let mod_input: Vec<_> = input.iter().map(|x| x * 811589153).collect();
    let mut decryptor = MixingDecryptor::from(mod_input);
    (0..10).for_each(|_| decryptor.mix());
    decryptor.grove_coordinates_sum()
}

Thankfully, we paid some attention to efficiency in part one, so part two runs in an acceptable time. Huzzah for premature engineering, I guess.

Wrap Up

Today’s puzzle was suspiciously similar to a certain cup game I recall from a couple of years ago. Thankfully, that memory served as the inspiration and reminder that many Vecs can make one LinkedList, and run pretty fast, too! With that experience in hand, today was mostly a matter of good variable naming in order to keep the operations straight. I’m getting started on catching up with my blog posts now that holiday travels are mostly over, and this puzzle was a nice “slow” one for a breather in between complicate graph algorithm puzzles.

Advent of Code 2022 - Day 19

Wed, 21 Dec 2022 00:00:00 +0000

Day 19 - Not Enough Minerals

Find the problem description HERE.

The Input - I Like The Way You Array

I hope you like code, because there’s a bunch of it today! For the inputs, the actual parsing bit really isn’t so bad. Each line has 5 sections, the first section indicates the blueprint ID and the remaining four sections indicate the recipes for making various robots. No, the interesting bit is just how darn useful it is to be able to define your own types and implement traits for them for various useful things. For example, I had no idea how handy it could be to index a wrapped array with an enum! Now, the code can be much more expressive!

use std::ops::{Add, AddAssign, Index, IndexMut, Mul, Sub, SubAssign};

/// Represents one of the resource types we're dealing with today.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
enum Resource {
    Ore,
    Clay,
    Obsidian,
    Geode,
}

/// This little newtype right here is the star of today's show, as
/// if you couldn't tell by all the basic arithmetic trait implementations
/// down below. This fella is being used to represent the number of
/// robots we have active, the number of resources we've gathered, and
/// the recipe costs for making new robots. Who knew one little array
/// could be so versatile!
#[derive(Debug, Default, Clone, Copy, PartialOrd, Ord, PartialEq, Eq, Hash)]
struct ResourceCountArray([u32; 4]);

/*----------------------------------------------------------------------------------
* This section contains a whole bunch of trait implementations for our hero, the
* ResourceCountArray. We can index the array by resource type, add them together,
* subtract them, multiply them by a scalar, and iterate over them. Truly a marvel!
*/

impl Index<Resource> for ResourceCountArray {
    type Output = u32;

    fn index(&self, index: Resource) -> &Self::Output {
        match index {
            Resource::Ore => &self.0[0],
            Resource::Clay => &self.0[1],
            Resource::Obsidian => &self.0[2],
            Resource::Geode => &self.0[3],
        }
    }
}

impl IndexMut<Resource> for ResourceCountArray {
    fn index_mut(&mut self, index: Resource) -> &mut Self::Output {
        match index {
            Resource::Ore => &mut self.0[0],
            Resource::Clay => &mut self.0[1],
            Resource::Obsidian => &mut self.0[2],
            Resource::Geode => &mut self.0[3],
        }
    }
}

impl Index<usize> for ResourceCountArray {
    type Output = u32;

    fn index(&self, index: usize) -> &Self::Output {
        &self.0[index]
    }
}

impl IndexMut<usize> for ResourceCountArray {
    fn index_mut(&mut self, index: usize) -> &mut Self::Output {
        &mut self.0[index]
    }
}

impl Add<ResourceCountArray> for ResourceCountArray {
    type Output = ResourceCountArray;

    fn add(self, other: ResourceCountArray) -> Self::Output {
        let mut sum: ResourceCountArray = Default::default();
        for (idx, (lhs, rhs)) in self.into_iter().zip(other.into_iter()).enumerate() {
            sum[idx] = lhs + rhs;
        }
        sum
    }
}

impl AddAssign<ResourceCountArray> for ResourceCountArray {
    fn add_assign(&mut self, rhs: ResourceCountArray) {
        for (idx, value) in rhs.into_iter().enumerate() {
            self[idx] += value;
        }
    }
}

impl SubAssign<ResourceCountArray> for ResourceCountArray {
    fn sub_assign(&mut self, rhs: ResourceCountArray) {
        for (idx, value) in rhs.into_iter().enumerate() {
            self[idx] -= value;
        }
    }
}

impl Mul<u32> for ResourceCountArray {
    type Output = ResourceCountArray;

    fn mul(self, rhs: u32) -> Self::Output {
        let mut product: ResourceCountArray = Default::default();
        for (idx, value) in self.into_iter().enumerate() {
            product[idx] = self[idx] * rhs;
        }
        product
    }
}

impl IntoIterator for ResourceCountArray {
    type Item = u32;
    type IntoIter = std::array::IntoIter<Self::Item, 4>;

    fn into_iter(self) -> Self::IntoIter {
        self.0.into_iter()
    }
}

/* -----------------------------------------------------------------------------------
*  Ok, back to normal non-trait stuff.
*/

impl ResourceCountArray {
    /// But only because _saturating_sub()_ isn't from a trait. We needed this one
    /// for a _very_ important performance optimization, though. You'll see that in
    /// the code for part one.
    fn saturating_sub(&self, other: ResourceCountArray) -> ResourceCountArray {
        let mut difference: ResourceCountArray = Default::default();
        for (idx, (lhs, rhs)) in self.into_iter().zip(other.into_iter()).enumerate() {
            difference[idx] = lhs.saturating_sub(rhs);
        }
        difference
    }
}

/// Represents a recipe for making a new robot
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct Recipe {
    bot: Resource,
    cost: ResourceCountArray, // See, everywere.
}

/// Represents an entire blueprint, with ID and recipe for each bot type.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct Blueprint {
    id: u32,
    recipes: [Recipe; 4],
}

/// The usual module wrapping the parsers for today's input. I'll be honest, the whole
/// inner module thing still seems a little odd to me, but it's the best way I could
/// come up with to namespace the parsing functions so far. So, I'm keeping it until
/// I can think of (or steal) a better idea.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::tag,
        character::complete::{newline, space1, u32},
        combinator::{opt, value},
        multi::separated_list0,
        sequence::{delimited, pair, preceded, separated_pair, tuple},
        Finish, IResult,
    };

    /// Nom parser for "ore" -> Resource::Ore
    fn ore(s: &str) -> IResult<&str, Resource> {
        value(Resource::Ore, tag("ore"))(s)
    }

    /// Nom parser for "clay" -> Resource::Clay
    fn clay(s: &str) -> IResult<&str, Resource> {
        value(Resource::Clay, tag("clay"))(s)
    }

    /// Nom parser for "obsidian" -> Resource::Obsidian
    fn obsidian(s: &str) -> IResult<&str, Resource> {
        value(Resource::Obsidian, tag("obsidian"))(s)
    }

    /// Nom parser for "geode" -> Resource::Geode
    fn geode(s: &str) -> IResult<&str, Resource> {
        value(Resource::Geode, tag("geode"))(s)
    }

    /// Parses any resource name into the relevant `Resource`
    fn resource(s: &str) -> IResult<&str, Resource> {
        alt((ore, clay, obsidian, geode))(s)
    }

    /// Nom parser for "4 ore" -> ResourceCountArray([4, 0, 0, 0])
    fn cost(s: &str) -> IResult<&str, ResourceCountArray> {
        let (s, (amt, resource)) = separated_pair(u32, space1, resource)(s)?;
        let mut cost: ResourceCountArray = Default::default();
        cost[resource] += amt;
        Ok((s, cost))
    }

    /// Nom parser for "3 ore and 14 clay" -> ResourceCountArray([3, 14, 0, 0])
    fn cost2(s: &str) -> IResult<&str, ResourceCountArray> {
        let mut resources: ResourceCountArray = Default::default();
        let (s, (cost1, cost2)) = separated_pair(cost, tag(" and "), cost)(s)?;
        Ok((s, cost1 + cost2))
    }

    /// Nom parser for
    ///   "Each ore robot costs 4 ore"
    ///     -> Recipe { bot: Resource::Ore, cost: ResourceCountArray([4, 0, 0, 0]) }
    fn recipe(s: &str) -> IResult<&str, Recipe> {
        let (s, _) = tag("Each ")(s)?;
        let (s, bot) = resource(s)?;
        let (s, _) = tag(" robot costs ")(s)?;
        let (s, cost) = alt((cost2, cost))(s)?;
        let (s, _) = tag(".")(s)?;
        Ok((s, Recipe { bot, cost }))
    }

    /// Nom parser for all four recipes from a line
    fn recipes(s: &str) -> IResult<&str, [Recipe; 4]> {
        let (s, (r1, r2, r3, r4)) = tuple((
            preceded(space1, recipe),
            preceded(space1, recipe),
            preceded(space1, recipe),
            preceded(space1, recipe),
        ))(s)?;
        Ok((s, [r1, r2, r3, r4]))
    }

    /// Nom parser for a single line of the input, producing a Blueprint
    fn blueprint(s: &str) -> IResult<&str, Blueprint> {
        let (s, id) = delimited(tag("Blueprint "), u32, tag(":"))(s)?;
        let (s, recipes) = recipes(s)?;
        Ok((s, Blueprint { id, recipes }))
    }

    /// Parses each line of the input into a Blueprint and return the list
    fn blueprints(s: &str) -> IResult<&str, Vec<Blueprint>> {
        separated_list0(newline, blueprint)(s)
    }

    /// Entrypoint for the parsing functions
    fn parse(s: &str) -> Result<Vec<Blueprint>> {
        let (_, result) = blueprints(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

const INPUT: &str = include_str!("../../input/19/input.txt");

/// Parse that input
fn read() -> Vec<Blueprint> {
    parser::parse(INPUT).unwrap()
}

We don’t actually use all those implementations while parsing the input, but we’ll use them in the actual puzzle. The code for part one is already cluttered enough though, and it’s enough to know ahead of time how these various operations work on the ResourceCountArray.

Part One - Oh Factory, My Factory

Looks like the blobs of superheated molten rock have stopped randomly flying through the air, so that’s good, I guess. But, you know what would be even better? Collecting some of that obsidian! Plus, if we get enough of it, we can probably build a nether portal to helps us get out of this jungle. The puzzle doesn’t say, but I assume the elephants are on board with this bit of a delay, since they didn’t seem to mind playing a gazillion rounds of rock Tetris with us a couple days ago.

use rayon::prelude::*;
use std::collections::{BinaryHeap, HashMap, HashSet};
use std::iter::zip;
use std::ops::{Index, IndexMut};
use Resource::*;

/// Solve Day 19, Part 1
///
/// I finally found a good an legitimate use for `rayon`! I probably could have used
/// parallel processing on Day 16, too. May try that later. Here, though, we can
/// process each blueprint in parallel, really helping with speed.
fn solve(input: &Vec<Blueprint>) -> u32 {
    input
        .par_iter()
        .map(|blueprint| Factory::new(*blueprint, 24))
        .map(|factory| factory.quality_level())
        .sum::<u32>()
}

/// It's a Factory that produces Factories! Represents each state of resource
/// production and includes the original blueprint, the number of turns remaining,
/// the current bot count, the current stockpile of resources, and the total number
/// of each type of resource produced.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
struct Factory {
    blueprint: Blueprint,
    remaining: u32,
    bots: ResourceCountArray,
    stockpile: ResourceCountArray,
    produced: ResourceCountArray,
}

/// Sorting for Factory, so that the state closest to completion floats to
/// the top of the Binary Heap we'll use for the graph search algorithm. "Greater"
/// values for Factory are those where the most geodes can possibly be produced
/// using the best-guess estimate.
impl Ord for Factory {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
        let self_estimate = self.best_estimate(Geode);
        let other_estimate = other.best_estimate(Geode);
        self_estimate.cmp(&other_estimate)
    }
}

impl PartialOrd for Factory {
    fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
        Some(self.cmp(other))
    }
}

impl Factory {
    /// Create a new Factory!
    fn new(blueprint: Blueprint, time: u32) -> Self {
        Factory {
            blueprint,
            remaining: time,
            bots: ResourceCountArray([1, 0, 0, 0]),
            stockpile: Default::default(),
            produced: Default::default(),
        }
    }

    /// Try to produce a bot from the given recipe. Attempts to fast-forward the
    /// state until the given bot is produced, if it can be. There are a few
    /// different guard clauses that aim to prevent creating new states that won't
    /// lead to the optimal solution.
    fn produce_recipe(&self, recipe: Recipe) -> Option<Factory> {
        let Recipe { bot, cost } = recipe;

        // Don't produce this recipe if the factory can't produce enough
        // resources to build this bot
        let max_production = (self.bots * self.remaining) + self.stockpile;
        if zip(cost, max_production).any(|(lhs, rhs)| lhs > rhs) {
            return None;
        }

        // If there's only one turn left, then skip it. This factory won't
        // produce anything else.
        if self.remaining == 1 {
            return None;
        }

        // If this factory could have produced the current recipe in its last
        // incarnation, then it should have produced that bot back then. Too
        // late, now!
        let last_turn_resources = self.stockpile.saturating_sub(self.bots);
        if zip(cost, last_turn_resources)
            .filter(|(lhs, _)| *lhs > 0)
            .all(|(lhs, rhs)| lhs < rhs)
        {
            return None;
        }

        /// If we're actually going to produce this bot, we need to advance the
        /// current Factory state minute-by-minute until we've gathered enough
        /// resources to produce the bot. Then we pay the price, produce the bot,
        /// and return the state.
        let mut new_state = *self;
        while new_state.remaining > 0 && self.bots == new_state.bots {
            let available = new_state.stockpile;
            new_state.remaining -= 1;
            new_state.stockpile += new_state.bots;
            new_state.produced += new_state.bots;

            if zip(available, cost).all(|(lhs, rhs)| lhs >= rhs) {
                new_state.bots[bot] += 1;
                new_state.stockpile -= cost;
            }
        }

        Some(new_state)
    }

    /// Identify all the next states that can be reached from the current Factory.
    /// Tries to produce one of each bot and includes a "wait" state where the
    /// Factory just lets time run out. This is for cases when not enough resources
    /// will be generated to produce any more bots before time runs out.
    fn next_states(&self) -> impl Iterator<Item = Factory> + '_ {
        let mut wait_state = *self;
        wait_state.stockpile += self.bots * self.remaining;
        wait_state.produced += self.bots * self.remaining;
        wait_state.remaining = 0;

        let wait_state_iter = std::iter::once(wait_state);

        self.blueprint
            .recipes
            .into_iter()
            .flat_map(|recipe| self.produce_recipe(recipe))
            .chain(wait_state_iter)
    }

    /// Identify the most possible resources of a given type that could be
    /// produced under ideal circumstances.
    fn best_estimate(&self, resource: Resource) -> u32 {
        // Assume that we can make one new bot per minute for
        // the remaining time. In that perfect scenario, how many
        // `resource` would we have a the end of time?
        // This is also our A* heuristic, which will always _overestimate_
        // how close we are to the goal. We're using a max heap,
        // so we need to overestimate to get an admissible heuristic.
        let resource_bots = self.bots[resource] + self.remaining;
        let new_resources = resource_bots * self.remaining;
        new_resources + self.produced[resource]
    }

    /// This is our unique identifier for a given Factory. It's the simplest
    /// value that identifies a Factory uniquely _enough_ to find the right
    /// solution.
    fn key(&self) -> ResourceCountArray {
        self.bots + self.produced
    }

    /// Performs a modified A* search through the possible Factory states,
    /// seeking a state that produces the most possible geodes.
    fn geodes_produced(&self) -> u32 {
        let mut heap = BinaryHeap::from([*self]);
        let mut seen = HashSet::new();
        let mut most_geodes = 0; // Used for optimization

        // So long as the heap still has items on it...
        while let Some(state) = heap.pop() {
            // If we reached a state where time runs out, we've identified
            // the state producing the most geodes, assuming we've implemented
            // the ordering of Factories correctly.
            if state.remaining == 0 {
                return state.stockpile[Geode];
            }

            // If we've seen this state already, skip it.
            if seen.contains(&state.key()) {
                continue;
            }

            // Otherwise, mark it as seen. Update the most geodes produced
            // by any state seen so far.
            seen.insert(state.key());
            most_geodes = most_geodes.max(state.produced[Geode]);

            for next_state in state.next_states() {
                // If we've seen this `next_state` before, skip it.
                if seen.contains(&next_state.key()) {
                    continue;
                }

                // If the best possible geode production for this state is still
                // less than the most geodes we've actually seen in a state so
                // far, skip it. The best estimate is an overestimate by design.
                if next_state.best_estimate(Geode) < most_geodes {
                    continue;
                }

                // Add this state to the heap to be checked.
                heap.push(next_state);
            }
        }

        // This should never happen
        unreachable!()
    }

    /// Calcualate the quality level of this Factory
    fn quality_level(&self) -> u32 {
        self.blueprint.id * self.geodes_produced()
    }
}

There’s a lot of code going into that, but the crux of it is a modified A* search through the interesting states of a graph, with some aggressive pruning of branches that can’t lead to the desired outcome of maximum obsidian gains. The trickiest bits were actually identifying the criteria for pruning branches as well as what value or values from the Factory would provide a sufficiently unique identifier without being so unique that we couldn’t really keep up with which states we’d seen before. Overall, this one required quite a bit of tuning, but I’m happy with how it turned out.

Part Two - Hungry Hungry Heffalumps

Looks like the elephants weren’t as on board with this process as we previously thought. Hope those blueprints tasted bad. Luckily, now they’re all fibered up and we have an extra eight minutes or so to run our Factory and three Blueprints left to check. So, we check the first three blueprints for 32 minutes each. Otherwise, it’s the same as part one.

/// Solve Day 19, Part 2
pub fn solve(input: &Input) -> Output {
    // That's right, it's basically the same as part one, with the slight
    // modifications that we're only examining the first three blueprints,
    // keeping the number of geodes per Blueprint as opposed to the quality
    // level, and multiplying instead of adding the results.
    input
        .par_iter()
        .take(3)
        .map(|blueprint| Factory::new(*blueprint, 32))
        .map(|factory| factory.geodes_produced())
        .product::<u32>()
        .into()
}

Nailed it!

Wrap Up

Today’s puzzle was an exercise in absolute frustration as my initial solution to this puzzle was pretty quickly achieved (for me), but the total runtime for input parsing and solving both parts was ~2.5 seconds! That’s unacceptably slow, which sparked the quest for the right optimizations. I tried a fair number of things, but the biggest performance gains came from choosing the right key for the seen list, skipping branches that couldn’t afford to build the bot I wanted ever, and skipping branches that could have produced a bot in a prior round but didn’t. Taken all together, I got runtime down to about 86ms, which was a massive improvement. Between that, the chance to use rayon for parallel procesing, and the absolute delight that was the ResourceCountArray, this was a pretty good day.

Advent of Code 2022 - Day 18

Mon, 19 Dec 2022 00:00:00 +0000

Day 18 - Boiling Boulders

Find the problem description HERE.

The Input - A “Notch” In Your Belt

Ooh, goody. Today we’re dealing with voxels! Parsing input today is pretty straightforward. Just three numbers, separated by commas. Given that I’m trying to catch up on blog posts, that’s all the exposition you’re getting today!


/// Represents a 1x1x1 cube in 3D space
#[derive(Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
struct Cube(i32, i32, i32);

// Just some convenience functions for working with Cubes
impl Cube {
    fn new(x: i32, y: i32, z: i32) -> Self {
        Cube(x, y, z)
    }

    fn inner(&self) -> (i32, i32, i32) {
        let Cube(x, y, z) = self;
        (*x, *y, *z)
    }
}

/// Convert a tuple of i32s into a Cube
impl From<(i32, i32, i32)> for Cube {
    fn from(value: (i32, i32, i32)) -> Self {
        let (x, y, z) = value;
        Cube(x, y, z)
    }
}

/// Module wrapping the parsing functions for today's puzzle input
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::tag,
        character::complete::{i32, newline},
        combinator::map,
        multi::separated_list0,
        sequence::{terminated, tuple},
        Finish, IResult,
    };
    use std::collections::HashSet;

    /// Nom parser for ("5," || "5") -> 5i32
    fn number(s: &str) -> IResult<&str, i32> {
        alt((terminated(i32, tag(",")), i32))(s)
    }

    /// Nom parser for "1,2,3" -> (1, 2, 3)
    fn coordinates(s: &str) -> IResult<&str, (i32, i32, i32)> {
        // Using tuple instead of separated_list1 here because I want
        // to avoid allocating the Vec
        tuple((number, number, number))(s)
    }

    /// Nom parser for "1,2,3" -> Cube(1, 2, 3)
    fn cube(s: &str) -> IResult<&str, Cube> {
        map(coordinates, Cube::from)(s)
    }

    /// Parses a list of input lines into a list of Cubes
    fn cubes(s: &str) -> IResult<&str, Vec<Cube>> {
        separated_list0(newline, cube)(s)
    }

    /// Parses the input file into a HashSet of Cubes
    pub fn parse(s: &str) -> Result<HashSet<Cube>> {
        let (_, result) = cubes(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result.into_iter().collect::<HashSet<_>>())
    }
}

const INPUT: &str = include_str!("../../input/18/input.txt");

/// Parse that input!
fn read() -> HashSet<Cube> {
    parser::parse(INPUT).unwrap()
}

That’s it, 3D points. Now, on to the show…

Part One - Drop It Like It’s Hot

Ah, yes. When one finds oneself standing underneath flying globs of lava, the only reasonable reaction is to estimate their volumes! Clearly. The elephants are on-board, so seems like it must be a good idea. The tricky bit here is that we can’t count on all the little blobbies to be connected, so we’ll need to account for that.

use std::collections::HashSet;
use std::ops::Add;

/// Solve Day 18, Part 1
fn solve(input: &HashSet<Cube>) -> u32 {
    let mut surface_area = 0;

    // For each cube in the input, look at each cube that shares
    // a face with it. For every one of those neighboring cubes that
    // is not lava, add one to the total surface area.
    for cube in input.iter() {
        for neighbor in cube.neighbors() {
            if !input.contains(&neighbor) {
                surface_area += 1;
            }
        }
    }

    surface_area
}

/// Represents an offset used to adjust a Cube location
#[derive(Debug, Clone, Copy)]
struct Offset(i32, i32, i32);

impl Offset {
    /// All the offsets of interest. Provides the offsets that will result
    /// in a Cube that shares a face with an existing Cube.
    const fn all() -> [Offset; 6] {
        [
            Offset(-1, 0, 0),
            Offset(1, 0, 0),
            Offset(0, -1, 0),
            Offset(0, 1, 0),
            Offset(0, 0, -1),
            Offset(0, 0, 1),
        ]
    }

    /// Convenience!
    fn new(x: i32, y: i32, z: i32) -> Self {
        Offset(x, y, z)
    }

    /// Convenience!
    fn inner(&self) -> (i32, i32, i32) {
        let Offset(x, y, z) = self;
        (*x, *y, *z)
    }
}

/// Allows for adding an Offset to a Cube to get a Cube offset from the original
impl Add<Offset> for Cube {
    type Output = Cube;

    fn add(self, offset: Offset) -> Self::Output {
        let (cx, cy, cz) = self.inner();
        let (ox, oy, oz) = offset.inner();
        let x = cx + ox;
        let y = cy + oy;
        let z = cz + oz;

        Cube::new(x, y, z)
    }
}

impl Cube {
    /// Get all the neighboring Cubes that share a face with this one.
    fn neighbors(&self) -> [Cube; 6] {
        let mut cubes = [Cube::default(); 6];
        let offsets = Offset::all();
        for (slot, offset) in cubes.iter_mut().zip(offsets.iter()) {
            *slot = *self + *offset;
        }
        cubes
    }
}

Turns out, we can account for that by checking each little voxel individually. Well, that wasn’t so bad. What about part two?

Part Two - It’s What’s on the Outside That Counts

Turns out, not all the lava is exposed to the open air, some of it is exposed to the “closed” air, i.e. the inside of the blob. No worries, we can find the outside of the blob by searching the area around the blob.

use std::collections::HashSet;
use std::ops::RangeInclusive;

/// Solve Day 18, Part 2
fn solve(input: &HashSet<Cube>) -> u32 {
    // Identify the bounding box that contains all the Cubes for the lava
    // plus at least one extra in each dimension.
    let bounds = input.get_bounds();

    // Adding up surface area, like before
    let mut surface_area = 0;

    // Prepare for a Depth-First Search through all the Cubes that are within
    // the bounding box but that _aren't_ lava. Each "air" cube that touches
    // a lava cube adds one to the total observed surface area.
    let mut stack = Vec::with_capacity(input.len() * 2);
    let mut seen = HashSet::with_capacity(input.len() * 2);

    // This isn't technically a corner of the bounding box or anything, but
    // I checked my input and there isn't any lava at this location. It really
    // doesn't matter _where_ you start the search, so long as it's a Cube
    // outside the lava blob.
    let start = Cube::new(0, 0, 0);
    stack.push(start);

    // So long as there are still Cubes outside the lava blob to check...
    while let Some(cube) = stack.pop() {
        // If the cube we're on has already been explored or it falls outside
        // the bounding box, skip it.
        if seen.contains(&cube) || !bounds.contains(&cube) {
            continue;
        }

        // If the cube we're on contains lava, then we add one to our surface area
        // and move on. We don't want to explore the lava-containing cubes.
        if input.contains(&cube) {
            surface_area += 1;
            continue;
        }

        seen.insert(cube);

        // For each cube that shares a face with the current Cube, if we haven't
        // explored it already, add it to the stack for later exploration.
        for neighbor in cube.neighbors() {
            if seen.contains(&neighbor) {
                continue;
            }
            stack.push(neighbor);
        }
    }

    surface_area
}

/// Represents the 3D range that contains all the air Cubes we want to explore,
/// encapsulating the lava Cubes.
struct Bounds(
    RangeInclusive<i32>,
    RangeInclusive<i32>,
    RangeInclusive<i32>,
);

/// This trait provides a convenient way to get the bounding box of
/// a HashSet of Cubes
trait GetBounds {
    fn get_bounds(&self) -> Bounds;
}

impl GetBounds for &HashSet<Cube> {
    /// Nothing fancy here. Identify the minimim and maximum values on each axis
    /// for all the lava-containing cubes, then set the bounding box to be one
    /// greater in each dimension. This leaves a one-wide gap around the lava
    /// blob that is OK to explore.
    fn get_bounds(&self) -> Bounds {
        let (mut min_x, mut max_x) = (0, 0);
        let (mut min_y, mut max_y) = (0, 0);
        let (mut min_z, mut max_z) = (0, 0);

        for cube in self.iter() {
            let (x, y, z) = cube.inner();
            min_x = min_x.min(x);
            max_x = max_x.max(x);
            min_y = min_y.min(y);
            max_y = max_y.max(y);
            min_z = min_z.min(z);
            max_z = max_z.max(z);
        }

        let x_range = (min_x - 1)..=(max_x + 1);
        let y_range = (min_y - 1)..=(max_y + 1);
        let z_range = (min_z - 1)..=(max_z + 1);

        Bounds(x_range, y_range, z_range)
    }
}

impl Bounds {
    /// Indicates whether a Cube lies within the Bounds
    fn contains(&self, cube: &Cube) -> bool {
        let (x, y, z) = cube.inner();
        let Bounds(x_range, y_range, z_range) = self;
        x_range.contains(&x) && y_range.contains(&y) && z_range.contains(&z)
    }
}

For some reason, I’m unreasonably fond of that little Bounds struct. I really can’t put a finger on why I like it so much, but I do like it.

Wrap Up

Well, I’m getting this blog post out late on the day after this puzzle was released, so I’m clearly a bit behind. Today was a bit of a breather, which I appreciate. Since it’s the day after, I can give you a dispatch from the future: tomorrow is going to be a tough one. Get ready!

Advent of Code 2022 - Day 17

Sun, 18 Dec 2022 00:00:00 +0000

Day 17 - Pyroclastic Flow

Find the problem description HERE.

The Input - Left, Left, Left Right Left

You know what’s the easy part of today’s puzzle? Parsing a string of two kinds of characters into Left/Right directions. You know what’s the fun part of today’s input? Making that list of characters into an infinite iterator! Yeah, my idea of fun may be a bit different than most. Ah well, more for me!


/// Represents a gust from the jets of gas, either to the left or right.
#[derive(Debug, Clone, Copy)]
enum Gust {
    Left,
    Right,
}

/// An iterator that produces gusts of gas in an repeating cycle
#[derive(Debug, Clone)]
struct GasJetIter {
    iter: Vec<Gust>,
    pub idx: usize,
}

/// Iterator implementation for `GasJetIter`. Just returns the values contained
/// in a repeating cycle.
impl Iterator for GasJetIter {
    type Item = Gust;

    fn next(&mut self) -> Option<Self::Item> {
        let result = Some(self.iter[self.idx]);
        self.idx = (self.idx + 1) % self.iter.len();
        result
    }
}

/// Convert a list of `Gust`s into a `GasJetIter`
impl From<Vec<Gust>> for GasJetIter {
    fn from(iter: Vec<Gust>) -> Self {
        GasJetIter {
            iter,
            idx: Default::default(),
        }
    }
}

/// Module to wrap the parsing functions for today's puzzle
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        character::complete::char,
        combinator::{map, value},
        multi::many1,
        Finish, IResult,
    };

    /// Nom parser for '<' -> Gust::Left
    fn push_left(s: &str) -> IResult<&str, Gust> {
        value(Gust::Left, char('<'))(s)
    }

    /// Nom parser for '>' -> Gust::Right
    fn push_right(s: &str) -> IResult<&str, Gust> {
        value(Gust::Right, char('>'))(s)
    }

    /// Nom parser for a Gust in either direction
    fn push(s: &str) -> IResult<&str, Gust> {
        alt((push_left, push_right))(s)
    }

    /// Nom parser for a list of Gusts
    fn pushes(s: &str) -> IResult<&str, Vec<Gust>> {
        many1(push)(s)
    }

    /// Nom parser to map a GasJetIter to a list of Gusts
    fn gas_jet_iter(s: &str) -> IResult<&str, GasJetIter> {
        map(pushes, GasJetIter::from)(s)
    }

    /// Main parsing function, attempts to parse the input into a GasJetIter and 
    /// return it.
    pub fn parse(s: &str) -> Result<GasJetIter> {
        let (_, result) = gas_jet_iter(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

const INPUT: &str = include_str!("../../input/17/input.txt");

/// Parse that input!
fn read() -> GasJetIter {
    parser::parse(INPUT).unwrap()
}

The neat thing here is that we can pass one mutable reference to that iterator around and always get the next Gust in the sequence. That’s going to come in handy for…

Part One - Drop It Like It’s Rock

Now, look, I’m as big a fan of Tetris as anyone. I’m not a super big fan of needing to prove my competence as a programmer to a gosh darn elephant! Especially given that they were there when we did that mapping through the steam valves. Well, time to prove that elephant wrong! For part one, we need to model what happens when 2022 oddly predictably shaped rocks fall into this tall cave chamber. I know how to make this make more sense: rocks as bits!

/// Solve Day 17, Part 1
fn solve(input: &GasJetIter) -> u32 {
    // We need an owned copy of the iterator so we can use it in both parts
    let mut gas_jets = input.to_owned();
    let total_rocks = 2022;

    // Since the maximum height of any rock is 4, a chamber than can hold
    // up to rocks * 4 levels will be plenty big enough.
    let mut chamber = Chamber::with_capacity(total_rocks * 4);

    // Produce rocks of the appropriate shape in a cycle, up to `total_rocks`
    // times.
    for rock in Rock::all().iter().cycle().take(total_rocks) {
        chamber.add_rock(&mut gas_jets, *rock);
    }

    // Repor the total height of the rocks in the chamber
    chamber.height() as u32
}

// You'll note that we're storing rocks as u32 integers. This makes collision
// checking much easier, as well as adding rocks to the chamber. It does, however
// make _reading_ the code a bit more difficult. These are the 32-bit integers
// that represent the column just to the left of the left wall and the column
// just to the right of the right wall. If any part of our rock overlaps one of 
// those spaces and the wind tries to push it in the corresponding direction,
// it won't move over.
const LEFT_WALL: u32 = 0x40404040;
const RIGHT_WALL: u32 = 0x01010101;

/// Represents one of the rocks.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
struct Rock(u32);

impl Rock {
    /// Produce a list of all five rock shapes, in order. This is what they look
    /// like in octal. Printed out in binary one byte at a time, with each byte 
    /// on a new line, they look like this (using . instead of 0 to make it easier
    /// to see):
    ///
    /// ...1111.  ....1...  .....1..  ...1....  ...11...
    /// ........  ...111..  .....1..  ...1....  ...11...
    /// ........  ....1...  ...111..  ...1....  ........
    /// ........  ........  ........  ...1....  ........
    const fn all() -> [Self; 5] {
        [
            Self(0x0000001E), // -
            Self(0x00081C08), // +
            Self(0x0004041C), // L
            Self(0x10101010), // |
            Self(0x00001818), // #
        ]
    }

    /// Try to move a rock over to the left or right from a gas jet
    /// within the chamber.
    fn shove(&mut self, push: Gust, levels: u32) {
        // Get a copy of the rock bits
        let mut pushed = self.0;

        match push {
            // If pushed to the left and not against the wall, move the rock
            // to the left.
            Gust::Left => {
                if self.0 & LEFT_WALL == 0 {
                    pushed = self.0 << 1
                }
            }

            // If pushed to the right and not against the wall, move the rock
            // to the right.
            Gust::Right => {
                if self.0 & RIGHT_WALL == 0 {
                    pushed = self.0 >> 1
                }
            }
        }

        // If the pushed rock isn't colliding with anything in the same levels
        // as it in the chamber, then update the rock's horizontal position.
        if pushed & levels == 0 {
            self.0 = pushed
        }
    }

    /// Check to see if this rock collides with another object. 
    fn collides(&self, other: u32) -> bool {
        self.0 & other > 0
    }

    /// Produce the bytes of the rock in order, skipping the empty bytes
    fn bytes(&self) -> impl Iterator<Item = u8> {
        self.0.to_le_bytes().into_iter().take_while(|b| *b > 0)
    }
}

/// Represents the chamber where the rocks are being dropped
#[derive(Debug, Default, Clone)]
struct Chamber(Vec<u8>);

impl Chamber {
    /// Create a new chamber with a set capacity
    fn with_capacity(n: usize) -> Self {
        Self(Vec::with_capacity(n))
    }

    /// Report the height of the rocks in the chamber
    fn height(&self) -> usize {
        self.0.len()
    }

    /// Add a new level (byte) to the chamber
    fn push(&mut self, level: u8) {
        self.0.push(level)
    }

    /// Get a 4-wide chunk of bytes from the chamber, starting at `level`.
    fn get_level_chunk(&self, level: usize) -> u32 {
        if level >= self.0.len() {
            return 0;
        }

        // Starting at `level`, take up to four bytes from the chamber, reverse
        // the production (so that the chunk is right-side up) of bytes, then 
        // convert the four bytes into a single u32 by shifting existing bits
        // left and adding each new byte to the first 8 bits after the shift.
        self.0
            .iter()
            .skip(level)
            .take(4)
            .rev()
            .fold(0, |acc, byte| (acc << 8) | *byte as u32)
    }

    /// Add a rock to the top of the chamber and allow it to fall until it
    /// comes to rest on another rock or the floor.
    fn add_rock(&mut self, gas_jets: &mut GasJetIter, mut rock: Rock) {

        // Start the rock out three levels above the top of chamber, which is
        // the top level with any rock parts.
        let mut level = self.height() + 3;

        // Until the rock comes to rest...
        loop {
            // Get the chunk of chamber levels starting at `level`
            let levels = self.get_level_chunk(level);

            // Get the next gust from the gas jets
            let jet = gas_jets.next().unwrap();

            // Attempt to shove the rock over
            rock.shove(jet, levels);

            // If the current level is above the highest level with a rock in it
            // in the chamber, drop the level and shove the rock again.
            if level > self.height() {
                level -= 1;
                continue;
            }

            // Now get the chunk of the chamber starting one level below where
            // we started. This simulates the rock dropping down one level.
            let levels = self.get_level_chunk(level.saturating_sub(1));

            // Check to see if the rock would collide with anything if it moved down.
            let collision = rock.collides(levels);

            // If we reached the floor or would collide with another rock...
            if level == 0 || collision {

                // Add the rock to the chamber, layer by layer. Where there's a
                // chamber level already there for the layer of rock we're adding,
                // just add the layer of rock to the level. Otherwise, push the 
                // layer to the top of the chamber's bytes.
                for byte in rock.bytes() {
                    if level < self.height() {
                        self.0[level] |= byte;
                    } else {
                        self.push(byte);
                    }
                    level += 1;
                }
                break;
            }

            // If the rock doesn't need to stop due to the floor or collision, keep
            // going, dropping the rock another level and going again.
            level -= 1;
        }
    }
}

Granted, the whole bitwise thing is probably a bit of a questionable choice, but, as we have established, I have a bit of a strange sense of fun, and that includes operating on bits to speed up execution times. In this case, it meant sub-millisecond run times for this part. Actually, spoiler alert, this approach manages to parse the input and run both parts in around half a millisecond. Speedy!

Part Two - Never Enough! Never, Never!

Ok, these elephants are really starting to grind my gears! I mean, I could calculate how tall this theoretical rock tower will be after ONE TRILLION rocks fall through the chamber. Or I could just leave the elephants in the cave and let them figure it out. Good thing for them I like coding puzzles.

use std::collections::HashMap;

/// Solve Day 17, Part 2
fn solve(input: &GasJetIter) -> u32 {
    // We need an owned copy of the iterator so we can use it in both parts
    let mut gas_jets = input.to_owned();
    let total_rocks = 1_000_000_000_000; // That's a _lot_ of rocks...
    let mut rocks_added = 0; // Number of rocks added to the chamber

    // Keep up with the states we've seen of the chamber before. The state includes
    // the top 8 levels of the chamber, the shape of the last rock added to the 
    // chamber, and the current internal index of the `gas_jets`.
    let mut seen = HashMap::with_capacity(2048);

    // Why use 2048 as the capacity now? It's larger than the repeat length of the
    // chamber. What repeat length? Well, as it turns out, typically when Advent of
    // Code asks you what the state of some data structure will be one bazillion
    // iterations later, there's probably a cycle in the state of the data structure
    // somewhere that can be used to calculate the final state without needing to
    // simulate each step. In my case, the state of the top layers of the chamber
    // repeated every 1700 rocks dropped or so.
    let mut chamber = Chamber::with_capacity(2048);

    // How much height has been accumulated so far?
    let mut accumulated_height = 0;

    // An iterator to produce rocks of the appropriate shape in a cycle.
    let mut rock_types = Rock::all().into_iter().cycle();

    // Until we've added all gajillion rocks...
    while rocks_added < total_rocks {

        // Get the next rock, add it to the chamber, account for it, and if the 
        // chamber has fewer than 8 levels, do it again. We're checking the state
        // based on the top 8 levels, so no checking until we have at least 8 levels.
        let rock = rock_types.next().unwrap();
        chamber.add_rock(&mut gas_jets, rock);
        rocks_added += 1;
        if chamber.height() < 8 {
            continue;
        }

        // Check to see if we've seen this state of the top 8 levels of the chamber
        // before. If so, time to use that cycle!
        let state = (chamber.skyline(), rock, gas_jets.idx);
        if let Some((prev_rocks_added, prev_height)) = seen.get(&state) {
            // The number of rocks added in each repeating cycle.
            let repeat_len: usize = rocks_added - prev_rocks_added;

            // The number of repeats left before we add the final rock.
            let repeats: usize = (total_rocks - rocks_added) / repeat_len;

            // Add all the rocks in all the repeating cycles between here and the end.
            rocks_added += repeat_len * repeats;

            // Add the chamber height of the cycle to the accumulated height
            accumulated_height += repeats * (chamber.height() - prev_height);

            // Clear the map of seen states. We don't want to do everything inside
            // this `if` block again on the next iteration, after all.
            seen.clear();
            continue;
        }

        // If we haven't seen this state before, add it to the map and keep going.
        seen.insert(state, (rocks_added, chamber.height()));
    }

    // Report the current height of the chamber and the accumulated height from all
    // the cycles. The chamber will contain all the rocks dropped up to the start
    // of the second repetition of the cycle, then all the rocks that would be
    // dropped after the last full cycle ended.
    (chamber.height() as u64 + accumulated_height as u64).into()
}

impl Chamber {
    /// Get the 'skyline' of the top of the chamber. Really, it's just a u64 with 
    /// bits representing the top 8 levels of the chamber.
    fn skyline(&self) -> Option<u64> {

        // If the chamber is less than 8 levels tall, we can't take a skyline
        if self.height() < 8 {
            return None;
        }

        // Take the top 8 levels of the chamber and fold them into a 64-bit integer.
        let result = self
            .0
            .iter()
            .rev()
            .take(8)
            .fold(0u64, |acc, byte| (acc << 8) | *byte as u64);
        Some(result)
    }
}

Pro Tip: Anytime Advent of Code tells you to do a thing a ridiculous number of times, there’s probably some cycle in there that you can exploit. Today’s puzzle is no different! Since the pattern of dropping rocks repeats, you just need to know the height of the tower before the pattern, the height added by each repeat of the pattern, the number of repeats, and the height added after the last full repeat of the pattern. Then, math!

Wrap Up

This was my favorite puzzle so far! We had a lot of interesting “bits” today (see what I did there?). Infinite iterators, bitwise operations, stacking bytes, and infeasibly large numbers. What’s not to love? This is a good level of difficulty for this part of the year, and while it took me a while to work out the strategy for leveraging bits as rocks, once I started going down the path of using boolean arrays, I knew it was just one short step to bits! I’m still a bit behind on my blog posts, so I can tell you now that Day 18 is also interesting, so come on back for that one!

Advent of Code 2022 - Day 16

Sat, 17 Dec 2022 00:00:00 +0000

Day 16 - Proboscidea Volcanium

Find the problem description HERE.

The Input - Got Me Under Pressure

Today’s input is a lot like yesterday’s, at least in initial presentation. Each line has three pieces of useful information, with a bunch of verbiage that needs to be ignored surrounding those three pieces. We’ll want the current valve’s label, the pressure that can be released by that valve, and the other valves that can be reached by tunnel. The big difference here is that the algorithms for solving the puzzle really benefit from cutting down the input from the information as presented to a much more condensed graph structure where only the paths between the valves that actually release pressure are included. That part takes quite a bit of work, but it makes it worth it when our solution runs in milliseconds instead of hours.

use std::collections::HashMap;
use itertools::Itertools;

/// Represents a line from the input, parsed to pull out the relevant values.
/// Using this intermediate data structure because the _actual_ input gets
/// a lot of massaging before it's ready for use.
#[derive(Debug)]
struct ParsedInput<'a> {
    label: &'a str,
    flow: u32,
    leads_to: Vec<&'a str>,
}

impl<'a> ParsedInput<'a> {
    fn new(label: &'a str, flow: u32, leads_to: Vec<&'a str>) -> Self {
        Self {
            label,
            flow,
            leads_to,
        }
    }
}

/// Conversion for a tuple containing the parsed input values to a `ParsedInput`.
/// Really, `ParsedInput` is just a tuple with appropriate names.
impl<'a> From<(&'a str, u32, Vec<&'a str>)> for ParsedInput<'a> {
    fn from(value: (&'a str, u32, Vec<&'a str>)) -> Self {
        let (label, flow, leads_to) = value;
        ParsedInput::new(label, flow, leads_to)
    }
}

/// Module wrapping the parsing functions for parsing the input.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::tag,
        character::complete::{alpha1, newline, u32},
        combinator::{map, verify},
        multi::separated_list1,
        sequence::{delimited, preceded, tuple},
        Finish, IResult,
    };

    /// Parses a valve label, which is always a string of two capital letters.
    fn label(s: &str) -> IResult<&str, &str> {
        let ver_fn = |s: &str| s.len() == 2 && s.chars().all(|c| c.is_ascii_uppercase());
        verify(alpha1, ver_fn)(s)
    }

    /// Nom parser for "Valve AA" -> "AA"
    fn valve(s: &str) -> IResult<&str, &str> {
        preceded(tag("Valve "), label)(s)
    }

    /// Parses the flow rate of a valve
    fn flow(s: &str) -> IResult<&str, u32> {
        delimited(tag(" has flow rate="), u32, tag(";"))(s)
    }

    /// Parses the list of valves that are listed at the end of each input line.
    /// Note that the prefixes use proper subject-verb agreement.
    fn leads_to(s: &str) -> IResult<&str, Vec<&str>> {
        let prefix1 = tag(" tunnels lead to valves ");
        let prefix2 = tag(" tunnel leads to valve ");
        preceded(alt((prefix1, prefix2)), separated_list1(tag(", "), label))(s)
    }

    /// Parses a line of the input into a `ParsedInput`
    fn valve_map_entry(s: &str) -> IResult<&str, ParsedInput> {
        map(tuple((valve, flow, leads_to)), ParsedInput::from)(s)
    }

    /// Parses multiple lines from the input into a list of `ParsedInput`s
    fn valve_map_entries(s: &str) -> IResult<&str, Vec<ParsedInput>> {
        separated_list1(newline, valve_map_entry)(s)
    }

    /// Main parsing function, attemtps to read the input file as a string into
    /// a list of `ParsedInput`s.
    pub fn parse(s: &str) -> Result<Vec<ParsedInput>> {
        let (_, result) = valve_map_entries(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

/// Represents a valve. Includes fields for its ID and flow rate. The ID for
/// a valve is a u64 with a single bit set. This makes keeping up with which
/// valves have been opened as easy as bitwise -or- between multiple valves.
#[derive(Debug, Copy, Clone)]
struct Valve {
    id: u64,
    flow: u32,
}

impl Valve {
    fn new(id: u64, flow: u32) -> Self {
        Valve { id, flow }
    }
}

/// Represents a graph indicating the connections between valves. Edges are a list
/// of lists, where each list contains a pair of (edge index, distance to edge). For
/// example, if edges[0] == [(1, 2), (5, 3)], that indicates that from the valve
/// at index [0], the valve at index [1] can be reached in 2 steps and the valve at
/// index [5] can be reached in 3 steps.
/// The nodes are just the list of `Valve`s at an index that corresponds to an index
/// in `edges`. For example, if nodes[0] is valve "AA", then edges[0] indicates the
/// valves that can be reached from valve "AA".
#[derive(Debug)]
pub struct ValveMap {
    pub edges: Vec<Vec<(usize, u32)>>,
    pub nodes: Vec<Valve>,
}

impl ValveMap {
    fn new(edges: Vec<Vec<(usize, u32)>>, nodes: Vec<Valve>) -> Self {
        Self { edges, nodes }
    }
}

/// Convert a list of parsed input lines into a ValveMap
impl From<Vec<ParsedInput<'_>>> for ValveMap {
    fn from(value: Vec<ParsedInput>) -> Self {
        // The first part is the easy part, the nodes (valves). We set each ID
        // sequentially and extract the flow rate from the parsed input line.
        let mut nodes = Vec::new();
        for (idx, entry) in value.iter().enumerate() {
            let id = 2u64.pow(idx as u32);
            let flow = entry.flow;
            let valve = Valve::new(id, flow);
            nodes.push(valve);
        }

        // Given the fact that valves and their corresponding paths out are stored
        // and referenced by index in the ValveMap and they are given by label
        // (like "AA") by the input lines, it's handy to be able to get the appropriate
        // index for a valve by it's label.
        let label_idx_map = value
            .iter()
            .enumerate()
            .map(|(idx, entry)| (entry.label, idx))
            .collect::<HashMap<_, _>>();

        // The first step in preparing the `ValveMap` is to figure out the minimum
        // distance from each valve to each other valve. This is an implementation of
        // a thing I just learned about today called the 'Floyd-Warshall' algorithm.
        // The TLDR is that we're creating a 2D vector where each row represents a
        // valve to travel from, each column represents a valve to travel to, and the
        // value at that grid intersection is the cost. To begin, we set all the travel
        // distances to (essentially) infinity, then for each parsed input line telling
        // us which valves are directly connected, set those distances to 1, since we
        // know it takes 1 minute to travel each direct connection
        let mut dist_matrix = vec![vec![u32::MAX; value.len()]; value.len()];
        for (idx, entry) in value.iter().enumerate() {
            dist_matrix[idx][idx] = 0;
            for neighbor in entry.leads_to.iter() {
                let neighbor_idx = label_idx_map[neighbor];
                dist_matrix[idx][neighbor_idx] = 1;
            }
        }

        // With the direct connections in place, we check over every 3-wise
        // permutation of grid indices. Then we compare the distance from valve [i] to
        // valve [j] directly and the distance from valves [i] > [k] > [j]. If the path
        // with the detour is shorter than the direct path, update the distance
        // from [i] > [j] with the shorter distance.
        for permutation in (0..value.len()).permutations(3) {
            let (k, i, j) = (permutation[0], permutation[1], permutation[2]);
            let detour_dist = dist_matrix[i][k].saturating_add(dist_matrix[k][j]);
            if detour_dist < dist_matrix[i][j] {
                dist_matrix[i][j] = detour_dist;
            }
        }

        // Now that we know the shortest distance between all pairs of valves, we
        // build out our list of edges. We'll only include edges to valves that
        // actually release some amount of pressure (more than 0).
        let mut edges = Vec::new();
        for (start, valve) in nodes.iter().enumerate() {
            // For each possible destination valve, decide whether it should be
            // added to the list of edges from the [start] node.
            let mut edges_from = Vec::new();
            for (end, end_valve) in nodes.iter().enumerate() {
                // Don't include edges where the destination is the same
                // as the start or the valve's flow rate is zero.
                if start == end || end_valve.flow == 0 {
                    continue;
                }

                // Otherwise, add the edge as the destination index and the
                // minimum distance from [start] to [end].
                edges_from.push((end, dist_matrix[start][end]));
            }

            edges.push(edges_from);
        }

        ValveMap::new(edges, nodes)
    }
}

const INPUT: &str = include_str!("../../input/16/input.txt");

fn read() -> ValveMap {
    let entries = parser::parse(INPUT).unwrap();
    ValveMap::from(entries)
}

Whew, that bit of data structure manipulation really took a lot out of me. There were a lot of moving parts there, and it took me a while to get the code into a shape I approved of. Really, I’d prefer a version of the ValveMap without nodes for the “non-productive” valves, but in the end the code is a lot cleaner if I just leave them in and ignore them. This keeps me from needing to re-calculate the indices or use HashMaps, both of which introduce different types of overhead.

Part One - Elephants. Really?

The distress beacon, the one in the one space that our sensors couldn’t detect, was actually being operated by a parade of elephants. In a cave. With pipes and steam valves. There’s a lot of loose ends that are going to need to be tied up this year, that’s for sure. Ok, whatever, we’re helping elephants by spending 30 minutes opening valves in the right order. Hope it doesn’t take hours to figure out what that order should be…

/// Solve Day 16, Part 1
///
/// I'm not satisfied with this solution. We're essentially performing a depth-first
/// search starting from "AA" and identifying _every_ path through the notable valves
/// then returning the maximum pressure released by _any_ path. I'm quite certain
/// that there's an A* implementation that could do this much more efficiently, but
/// I'm struggling to develop an appropriate penalty function. I'll come back to this
/// one.
fn solve(input: &ValveMap) -> u32 {
    // Start at valve "AA"
    let state = TravelState::default();
    let mut open = vec![state];

    // Depth-first seach starting with "AA". Every time we hit a state where
    // time has run out, we check the total pressure released and update
    // the maximum pressure if necessary.
    let mut max_released = 0;

    // While the search stack has items remaining...
    while let Some(state) = open.pop() {
        // Check the state on the top of the stack. If time is up, try to update
        // the max pressure released and move on to the next item in the stack.
        if state.remaining == 0 {
            max_released = max_released.max(state.released);
            continue;
        }

        // If the state is an intermediate state (time still remaining), then add
        // each possible next state to the stack.
        for next_state in state.next_states(input) {
            open.push(next_state);
        }
    }

    // Return the maximum pressure released by any path through the valves
    max_released
}

/// Represents the state of a path through the valves. Indicates current location
/// as a node index, the set of open valves, the amount of time remaining, and
/// the total pressure that will be released once time runs out given the valves
/// open.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
struct TravelState {
    location: usize,
    valves_open: u64,
    remaining: u32,
    released: u32,
}

impl Default for TravelState {
    fn default() -> Self {
        TravelState {
            location: Default::default(),
            valves_open: Default::default(),
            remaining: 30, // Default to 30 minutes remaining
            released: Default::default(),
        }
    }
}

impl TravelState {
    /// Return a list of possible next states that can be reached from the
    /// current state.
    pub fn next_states(&self, map: &ValveMap) -> Vec<TravelState> {
        let mut out = Vec::new();

        // For each neighboring valve (and the distance to get to it)...
        for (neighbor, distance) in map.edges[self.location].iter() {
            // If the distance to the neighbor is to far to reach in the
            // time remaining or that valve is already open, then skip that
            // neighbor as a possible next state.
            if *distance >= self.remaining {
                continue;
            }
            let valve = map.nodes[*neighbor];
            if valve.id & self.valves_open > 0 {
                continue;
            }

            // Update the next state by subtracting the distance traveled from the
            // time remaining, with one extra for opening the destination valve.
            // Set the location of the next state to the neighbor index and add
            // the set bit for the valve ID to the value keeping track of which
            // valves are already open. When opening a new valve, add the flow rate
            // of that valve times the remaining time to the total pressure released
            // by this state, since we already know that valve will remain open
            // for the rest of the time, releasing its flow rate each minute.
            let mut new_state = *self;
            new_state.location = *neighbor;
            new_state.valves_open |= valve.id;
            new_state.remaining -= (distance + 1);
            new_state.released += (new_state.remaining * valve.flow);
            out.push(new_state);
        }

        // If there aren't any neighbors to travel to, either because all the valves
        // are already open or the travel time is more than time remaining, then we
        // can just "wait it out", staying put until time runs out.
        if out.is_empty() {
            let mut wait_state = *self;
            wait_state.remaining = 0;
            out.push(wait_state)
        }

        out
    }
}

Well, there you have it. I don’t love this approach, but it does run in ~13ms on my computer, so it’s not painfully slow. I can’t shake the feeling that it could be much better, though. Regardless, it works, and considering I’ve fallen a bit behind my pace on solutions and blog posts due to family commitments and the difficulty spike, I’m going to go ahead and let it go. Perhaps I’ll get a chance to come back to it on a later day or even after Christmas. Either way, star earned!

Part Two - A Helping “Hand”

At least the elephants are smart! Well, one of them, anyway. Honestly, it’s a good thing that only one elephant wants to help, otherwise the computation for maximizing valve-opening efficiency could get really wild. As it it, adding in one elephant led me to relying on some…questionable… tactics.

/// Solve Day 16, Part 2
///
/// This part is also a bit hacky. Here we're again producing every possible end
/// state from walking through and opening valves, just in 26 minutes instead of
/// 30. With that list of possible paths through the valves, we check the paths
/// that release the most pressure for two that open different sets of valves.
/// The total pressure released from the most pressure-releasing pair of
/// non-overlapping paths is the most pressure that two actors can release working
/// together.
fn solve(input: &ValveMap) -> u32 {
    // Now the initial state starts with only 26 minutes remaining.
    let mut state = TravelState {
        remaining: 26,
        ..Default::default()
    };
    let mut open = vec![state];

    // Instead of tracking the most pressure released, we're collecting all possible
    // final states.
    let mut best_results = Vec::new();
    while let Some(state) = open.pop() {
        if state.remaining == 0 {
            best_results.push(state);
            continue;
        }

        for neighbor in state.next_states(input) {
            open.push(neighbor);
        }
    }

    // Now we sort the final states by pressure released
    best_results.sort_unstable();

    // How many of the most productive states should be considered? This is the
    // 1337 hax. If we don't check enough of the most productive states, we'll
    // get the wrong answer. So, how many should we check? Enough until we get the
    // right answer! Honestly I started high and just started reducing the number
    // until I got low enough that this function started producing the wrong
    // answer.
    let depth = 285;

    // Notice that we're iterating backwards over the list of results, since
    // it's sorted by ascending total pressure released. For each top result, we
    // check down the list for the next result that doesn't overlap. There's a
    // possibility that this wouldn't work and we'd need to find a few pairs
    // this way and get their maximum, but for my input the first pair found
    // through this strategy produces the correct result.
    for (idx, result1) in best_results.iter().rev().enumerate().take(depth) {
        for result2 in best_results.iter().rev().skip(idx + 1).take(depth) {
            if result1.valves_open & result2.valves_open > 0 {
                continue;
            }
            let max = result1.released + result2.released;
            return max;
        }
    }

    // If we get this far, we've failed.
    panic!("Could not solve part two!");
}

/// Implement ordering for travel states so we can sort the list above. We'll
/// sort by total pressure released.
impl Ord for TravelState {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
        self.released.cmp(&other.released)
    }
}

impl PartialOrd for TravelState {
    fn partial_cmp(&self, other: &Self) -> Option<std::cmp::Ordering> {
        Some(self.cmp(other))
    }
}

That’s right, I’m not going to try keeping up with the combinatoric explosion of double the possible next states for each existing state. Instead, I’m honestly using a little bit of “Christmas Faith” to assume that two of the most productive end states are mutually exclusive and represent a path for me and a path for the elephant that will, together, result in the best possible valve-turning outcome. Foolproof.

Wrap Up

So, I was dissatisfied with my result until I started reading through other people’s experiences today, especially considering the run times some folks are experiencing. I also thought I’d find someone with a good A* implementation for part one I could shamelessly pull from, but so far, no dice. Honestly, I feel a bit better seeing that. I truly put a lot of effort into getting that input into a shape I thought would work for an efficient solution, and it seems like I succeeded there. I’m also glad I Googled for finding the shortest pairwise distances in a graph, otherwise I was prepared to do a bunch of Dijkstra’s instead of the more concise Floyd-Warshall algorithm. The Wikipedia article was actually helpful this time, too. I usually find those algorithm articles to be a bit dense for my taste, so that was a welcome surprise. All in all, a tough day, but a good day.

Advent of Code 2022 - Day 15

Fri, 16 Dec 2022 00:00:00 +0000

Day 15 - Beacon Exclusion Zone

Find the problem description HERE.

The Input - Who Senses the Sensors?

Today’s puzzle has us extracting the x/y coordinates of a sensor and a beacon from each line. There’s a lot of extra stuff on each line to ignore, so that’s what we’ll do! We’ll also need to know about the range of each sensor, which we can get from the distance of the beacon from the sensor.

/// Represents a point in the 2D plane where our sensors are located
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash, PartialOrd, Ord)]
struct Point(isize, isize);

impl Point {
    // Calculate the Manhattan Distance from one Point to another Point
    pub fn distance_to(&self, other: &Self) -> usize {
        let Point(x1, y1) = self;
        let Point(x2, y2) = other;
        x1.abs_diff(*x2) + y1.abs_diff(*y2)
    }
}

/// Easily create a Point from a tuple of i32's. This is mostly here because
/// the `nom` parsers don't provide isize directly.
impl From<(i32, i32)> for Point {
    fn from(value: (i32, i32)) -> Self {
        let (x, y) = value;
        Point(x as isize, y as isize)
    }
}

/// Represents one of our sensors. Encapsulates the location of the beacon it is
/// detecting and the Sensor's detection range.
#[derive(Debug, Copy, Clone, PartialEq, Eq, PartialOrd, Ord)]
struct Sensor {
    location: Point,
    beacon: Point,
    range: usize,
}

impl Sensor {
    fn new(location: Point, beacon: Point) -> Self {
        let range = location.distance_to(&beacon);
        Sensor {
            location,
            beacon,
            range,
        }
    }
}

/// Convert a tuple of Points into a Sensor. The first Point is the location of the
/// Sensor, the second is the location of the beacon.
impl From<(Point, Point)> for Sensor {
    fn from(value: (Point, Point)) -> Self {
        let (location, beacon) = value;
        Sensor::new(location, beacon)
    }
}

/// Internal module wrapping the `nom` parser for the input
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        bytes::complete::take_till,
        character::{
            complete::{i32, newline},
            is_alphabetic, is_digit,
        },
        combinator::{map, recognize},
        multi::separated_list0,
        sequence::{pair, preceded},
        Finish, IResult,
    };

    /// Nom parser to skip everything that's not a number or minus sign
    fn till_number(s: &str) -> IResult<&str, &str> {
        take_till(|c: char| c.is_ascii_digit() || c == '-')(s)
    }

    /// Nom parser to parse an i32 with a bunch of cruft in front of it
    fn prefixed_number(s: &str) -> IResult<&str, i32> {
        preceded(till_number, i32)(s)
    }

    /// Nom parser to take the first two found numbers and return a Point from them
    fn point(s: &str) -> IResult<&str, Point> {
        map(pair(prefixed_number, prefixed_number), Point::from)(s)
    }

    /// Get the two Points from an input line
    fn sensor(s: &str) -> IResult<&str, Sensor> {
        map(pair(point, point), Sensor::from)(s)
    }

    /// Parse all lines from the input into a list of Sensors
    fn sensors(s: &str) -> IResult<&str, Vec<Sensor>> {
        separated_list0(newline, sensor)(s)
    }

    /// Parse the input, returns a list of Sensors
    pub fn parse(s: &str) -> Result<Vec<Sensor>> {
        let (_, result) = sensors(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

const INPUT: &str = include_str!("../../input/15/input.txt");

/// Parse that input!
fn read() -> Vec<Sensor> {
    let mut input = parser::parse(INPUT).unwrap();
    input.sort_unstable();
    input
}

The trickiest bit for parsing today was forgetting to account for the minus sign in front of negative x/y position values. Got the wrong answers a few times before realizing I had some numbers that were supposed to be negative as positive. Need to remember that.

Part One - A New Hand Touches the Beacon

Ah, yes, back to tracking down the distress beacon with lots of computation! I’m guessing the sensors can only be deployed once, huh? Couldn’t just tell each sensor to move around a bit to try finding the distress beacon? Nah, that wouldn’t work. Let’s write some code!

use itertools::Itertools;

/// Solve Day 15, Part 1
fn solve(input: &[Sensor]) -> u32 {
    let row = 2_000_000; // Our hard-coded row of interest

    // Identify a RowRange for each sensor indicated the furthest left and furthest
    // right point detected by each sensor. These RowRanges may overlap, though, so
    // we need to 'condense' the ranges so we don't double-count any points. This
    // part depends on the input being sorted ahead of time, so that the RowRanges
    // come out sorted, so that all the RowRanges that can be condensed will be
    // encountered one after another. If the input isn't sorted here, you'll get a
    // different (wrong) answer.
    let mut ranges: Vec<RowRange> = Vec::new();
    for range in input.iter().flat_map(|s| s.row_range_sensed(row)) {
        // If the current range can be merged with the last range in `ranges`, do so.
        // Otherwise, just push the current range to the list.
        if let Some(last_rng) = ranges.last_mut() {
            if last_rng.overlaps(&range) {
                last_rng.merge(&range);
            }
            continue;
        }
        ranges.push(range);
    }

    // Count the number of observable positions on the target row, defined by
    // the limits of the `ranges`.
    let sensed_on_row = ranges.iter().map(|r| r.count_positions()).sum::<usize>();

    // We'll need to subtract out the number of beacons on the row, since those
    // points definitely _can_ contain a beacon.
    let beacons_on_row = input
        .iter()
        .filter_map(|s| s.beacon_on_row(row))
        .unique()
        .count();

    let definitely_not_beacons = sensed_on_row - beacons_on_row;
    (definitely_not_beacons as u32)
}

/// Represents a range of points on a given row of the scan. Includes the start and
/// end points on that row.
#[derive(Debug)]
struct RowRange(isize, isize);

impl RowRange {
    /// Does this range overlap another?
    fn overlaps(&self, other: &Self) -> bool {
        other.1 >= self.0 && self.1 >= other.0
    }

    /// Merge this range with another
    fn merge(&mut self, other: &Self) {
        *self = RowRange(self.0.min(other.0), self.1.max(other.1));
    }

    /// Count the number of positions in this range
    fn count_positions(&self) -> usize {
        self.0.abs_diff(self.1) + 1
    }
}

impl Sensor {
    /// Indicates if the sensor can detect the given Point
    pub fn can_detect(&self, point: &Point) -> bool {
        self.location.distance_to(point) <= self.range
    }

    /// Workhorse of part one. Identifies and returns the range of positions
    /// that can be detected by this sensor on the indicated row, as a RowRange.
    fn row_range_sensed(&self, row: isize) -> Option<RowRange> {
        let distance_to_row = self.location.1.abs_diff(row);
        if distance_to_row > self.range {
            return None;
        }

        // The spread indicates how much of the Manhattan distance for detection
        // is remaining to 'spread' out to the left and right. Essentially half
        // the width of the detection zone on this row.
        let spread = self.range - distance_to_row;
        let range_start = self.location.0.saturating_sub_unsigned(spread);
        let range_end = self.location.0.saturating_add_unsigned(spread);
        Some(RowRange(range_start, range_end))
    }

    /// If the beacon is on the given row, return the location of the beacon.
    /// Otherwise, return None.
    fn beacon_on_row(&self, row: isize) -> Option<Point> {
        if self.beacon.1 == row {
            return Some(self.beacon);
        }
        None
    }
}

The real trick here is not to try identifying each position on the row individually that can be sensed, but to identify the ranges of positions that can be sensed by the starting and ending positions on the row. I’m sure you could identify each position on the row uniquely, but those ranges are large.

Part Two - That One Spot You Can’t Reach

Wait, hold on, these sensor ranges are absolutely huge, and yet there is one and only one position in the midst of all those sensors that isn’t in range. Really? How unlucky can we be!? That’s fine, at least we get a pretty good logic puzzle out of the deal. The puzzle description gives us some constraints that we can use to make solving this part a lot less computationally expensive. Check out the comment in the code below for an explanation.

use itertools::Itertools;

/// Solve Day 15, Part 2
///
/// Well, I think this is my first "what the heck is he doing" comment of the year.
/// Yay! So, this solution relies on some assumptions, the biggest of which is that
/// the beacon we're searching for will lie one space outside the range of a Sensor.
/// Why can we assume that? Well, the only possible way that a gap of larger than
/// one could contain the beacon is if the beacon were located in one of the four
/// corner points of the allowed range. That would kind of suck, though, so it's
/// probably not how it is. If it turns out to be the case, then we only have four
/// possible answers to try, so it's a win-win. So, given that the beacon most
/// likely lies in a one-wide gap between sensor ranges, we can treat that gap like
/// a line. The other assumption is that there's more than one one-wide gap.
/// Otherwise, again, we'd have multiple unscanned spaces. That other gap would
/// necessarily have a slope with opposite sign of the first gap, making an X with
/// the center on the beacon. X marks the spot! So, if we can identify all the
/// one-wide gaps in the range of the sensors, we can identify all the places where
/// these gap-lines intersect. If we can find one intersection that can't be
/// detected by any sensor, that's the one we want.
fn solve(input: &[Sensor]) -> u64 {
    // Identify all the diagonal gaps between sensor detection ranges that are only
    // one space wide.
    let mut diagonal_gaps = Vec::new();
    for (sensor1, sensor2) in input.iter().tuple_combinations() {
        let Some(gap) = sensor1.gap_size(sensor2) else { continue; };
        if gap == 1 {
            diagonal_gaps.push(sensor1.diagonal_between(sensor2));
        }
    }

    // Identify all the points where these one-wide gaps intersect.
    let intersects = diagonal_gaps
        .iter()
        .tuple_combinations()
        .flat_map(|(diag1, diag2)| diag1.intersect(diag2))
        .unique()
        .collect_vec();

    // Check the intersections against all the sensors to identify the intersection
    // that cannot be detected by any Sensor. Now, for my input, there was only one
    // intersection that made it this far, but this check should make the solution
    // more robust for other inputs.
    'outer: for intersect in intersects {
        for sensor in input.iter() {
            if sensor.can_detect(&intersect) {
                continue 'outer;
            }
        }
        return intersect.tuning_frequency();
    }

    // Freak out if we can't find an intersection that can't be detected.
    panic!("Could not find the beacon!");
}

/// Represents a diagonal line. The Positive variant indicates a line with a slope
/// of 1 and the Negative variant indicates a line with a slope of -1.
#[derive(Debug)]
enum Diagonal {
    Positive(isize),
    Negative(isize),
}

impl Diagonal {
    /// Identify the point where two Diagonal lines intersect.
    fn intersect(&self, other: &Self) -> Option<Point> {
        // It's simple geometry! Which explains why it was so hard for me
        // to implement. Uses the formula for the two lines to calculate the
        // intersecting point, with some shortcuts because we know the slope
        // will either be positive or negative one for both lines, and if
        // the lines have the same slope, they're parallel and we can bail.
        use Diagonal::*;
        let (neg, pos) = match (self, other) {
            (Positive(pos), Negative(neg)) => (neg, pos),
            (Negative(neg), Positive(pos)) => (neg, pos),
            (Positive(_), Positive(_)) => return None,
            (Negative(_), Negative(_)) => return None,
        };
        let x = (neg - pos) / 2;
        let y = x + pos;
        Some(Point(x, y))
    }
}

impl Sensor {
    /// Find the size of the gap in the sensor range between two Sensors.
    /// If there's no gap (they overlap), return None.
    fn gap_size(&self, other: &Self) -> Option<usize> {
        let distance = self.location.distance_to(&other.location);
        let total_range = self.range + other.range;
        if total_range >= distance {
            return None;
        }
        Some(distance - total_range - 1)
    }

    /// Calculate the formula for the line that lies in the gap between two
    /// Sensor detection ranges. The line will lie diagonally just outside
    /// the range of `self`.
    fn diagonal_between(&self, other: &Self) -> Diagonal {
        let Point(x1, y1) = self.location;
        let Point(x2, y2) = other.location;
        let offset = self.range + 1;

        // Here, we identify two points on the diagonal line. We'll pick points just
        // outside the cardinal direction points of the `self` sensor range.
        let (p1x, p1y) = if x2 > x1 {
            (x1.saturating_add_unsigned(offset), y1)
        } else {
            (x1.saturating_sub_unsigned(offset), y1)
        };
        let (p2x, p2y) = if y2 > y1 {
            (x1, y1.saturating_add_unsigned(offset))
        } else {
            (x1, y1.saturating_sub_unsigned(offset))
        };

        // We know that the slope will either be 1 or -1, since these lines
        // are diagonals.
        let slope = (p2x - p1x) / (p2y - p1y);
        let intercept = p1y - (slope * p1x);
        if slope > 0 {
            Diagonal::Positive(intercept)
        } else {
            Diagonal::Negative(intercept)
        }
    }
}

impl Point {
    /// Calculate the tuning frequency the way the puzzle told us to.
    fn tuning_frequency(&self) -> u64 {
        (4_000_000 * self.0 as u64) + self.1 as u64
    }
}

You know, I didn’t come into this day’s puzzle expecting to need to think about the formulas for lines and calculating intersections.

Wrap Up

Today was a doozy! The biggest things that tripped me up were (a) thinking through the logic for solving part two and (b) translating line formula and equations into code. I honestly kept distracting myself by realizing that the special cases for lines meant I could simplify the code, but taking a while to get it written down. We’ve officially hit the part of Advent of Code where the difficulty has ramped up a bit. Given that this puzzle hit on a Thursday, I’m honestly a bit concerned about what Saturday will bring, given that puzzles tend to be tougher on the weekends. I learned a lot from today’s puzzle, though. Not so much about code, but about about how to think through these puzzles. It’s a good warm-up for the tougher puzzles that are coming. That said, I’m kind of hoping for a bit of a step-down tomorrow. Let’s find out!

Advent of Code 2022 - Day 14

Wed, 14 Dec 2022 00:00:00 +0000

Day 14 - Regolith Reservoir

Find the problem description HERE.

The Input - Can You Smell What the Rocks Are Cooking

Today, we’ve essentially got a list of lists. Each of our lines consists of a list of x/y coordinates separated by arrows, like so:

498,4 -> 498,6 -> 496,6
503,4 -> 502,4 -> 502,9 -> 494,9

Since we want to map sand flowing over the “lines of rock” indicated by the line segments indicated as starting and ending at these points, we’ll want to collect these points and all the points in those line segments into a map of some kind. Since we’re not given the dimensions of the cave system up-front. let’s go with a HashSet<Point>, where a Point indicates a point in the 2D space of the cave.

use itertools::Itertools;
use std::cmp::Ordering;
use std::collections::HashSet;
use std::ops::{Add, AddAssign};

/// Represents a point on the 2D grid where the rocks are
#[derive(Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
struct Point(u32, u32);

/// An offset to a point, used to adjust `Point`s
#[derive(Debug, Default, Clone, Copy)]
struct Offset(i32, i32);

impl Point {
    /// Calculate the unit offset from one `Point` to another. This represents
    /// the incremental step that, if taken repeatedly, will take you from
    /// `other` to `self`.
    fn offset_from(&self, other: &Self) -> Offset {
        let Point(x1, y1) = self;
        let Point(x2, y2) = other;
        match (x1.cmp(x2), y1.cmp(y2)) {
            (Ordering::Less, Ordering::Less) => Offset(-1, -1),
            (Ordering::Less, Ordering::Equal) => Offset(-1, 0),
            (Ordering::Less, Ordering::Greater) => Offset(-1, 1),
            (Ordering::Equal, Ordering::Less) => Offset(0, -1),
            (Ordering::Equal, Ordering::Equal) => Offset(0, 0),
            (Ordering::Equal, Ordering::Greater) => Offset(0, 1),
            (Ordering::Greater, Ordering::Less) => Offset(1, -1),
            (Ordering::Greater, Ordering::Equal) => Offset(1, 0),
            (Ordering::Greater, Ordering::Greater) => Offset(1, 1),
        }
    }
}

/// Implementation to allow adding an `Offset` to a `Point` to
/// move the `Point` in 2D space.
impl Add<Offset> for Point {
    type Output = Point;

    fn add(self, rhs: Offset) -> Self::Output {
        let Point(px, py) = self;
        let Offset(ox, oy) = rhs;
        let x = px.saturating_add_signed(ox);
        let y = py.saturating_add_signed(oy);
        Point(x, y)
    }
}

/// Module wrapping the input parser to parse lines from the input.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        bytes::complete::tag,
        character::complete::{newline, u32},
        multi::separated_list1,
        sequence::separated_pair,
        Finish, IResult,
    };

    /// Nom parser for "15,30" -> Point(15, 30)
    fn point(s: &str) -> IResult<&str, Point> {
        let (s, (first, second)) = separated_pair(u32, tag(","), u32)(s)?;
        Ok((s, Point(first, second)))
    }

    /// Nom parser to convert a list like
    /// "15,30 -> 15,45" -> [Point(15, 30), Point(15, 45)]
    fn point_list(s: &str) -> IResult<&str, Vec<Point>> {
        separated_list1(tag(" -> "), point)(s)
    }

    /// Nom parser to convert all lines to a list of lists of `Point`s
    fn point_lists(s: &str) -> IResult<&str, Vec<Vec<Point>>> {
        separated_list1(newline, point_list)(s)
    }

    /// Parse the input file into a list of lists of `Point`s
    pub fn parse(s: &str) -> Result<Vec<Vec<Point>>> {
        let (_, result) = point_lists(s).finish().map_err(|e| anyhow!("{e}"))?;
        Ok(result)
    }
}

/// A struct to house everything we need to iterate one space on the 2D grid
/// at a time to follow a line of rocks, given by a start and end `Point`.
/// We'll use this iterator to produce all the `Point`s containing rocks
/// between `start` and `end`.
struct RockLineIter {
    start: Point,        // The point where the rock line starts
    end: Point,          // The point where the rock line ends
    offset: Offset,      // The incremental change from `start` to `end`
    next: Option<Point>, // The next item to return from this iterator
}

/// A trait for a pair of points to implement to produce a list of rocky points
/// in the line from one point to another.
trait RockLine {
    fn rock_line(self) -> RockLineIter;
}

/// Take a pair of points and return a `RockLineIter`.
impl RockLine for (Point, Point) {
    fn rock_line(self) -> RockLineIter {
        let (start, end) = self;
        let offset = end.offset_from(&start);
        RockLineIter {
            start,
            end,
            offset,
            next: Some(start), // The first point returned is the start
        }
    }
}

/// Let `RockLineIter` be used for iteration! Produces all the points containing
/// rocks from `start` to `end`.
impl Iterator for RockLineIter {
    type Item = Point;

    fn next(&mut self) -> Option<Self::Item> {
        match self.next {
            None => None, // This is how we know when `RockLineIter` is empty
            Some(current) => {
                // If we're currently on the end point, then we've emptied the
                // iterator. Otherwise, the next point returned will be the
                // current point plus the offset.
                self.next = if current == self.end {
                    None
                } else {
                    Some(current + self.offset)
                };

                Some(current)
            }
        }
    }
}

const INPUT: &str = include_str!("../../input/14/input.txt");

/// Parse the input!
pub fn read() -> HashSet<Point> {
    // List of lists of `Point`s, basically the input file
    let point_lists = parser::parse(INPUT).unwrap();

    // The set of points that contain obstacles (rocks)
    let mut obstacles = HashSet::new();

    // For each list of `Point`s...
    for point_list in point_lists {
        // For each pair of points in that list...
        for point_pair in point_list.into_iter().tuple_windows::<(_, _)>() {
            // For each "rocky" point in the line of rocks...
            for rock_point in point_pair.rock_line() {
                // Add that rock point to the set of obstacles
                obstacles.insert(rock_point);
            }
        }
    }

    // Return our set of points that sand can't cross
    obstacles
}

A little bit of extra work there setting up and running the iterators for lines of rock, but worth it for the practice!

Part One - Don’t Go Chasin’ Waterfalls

See, this is why you don’t go running into deep dark caves after mysterious distress signals. Now we’re trapped over some bottomless abyss with sand flowing down from above. Great. And we’re looking at things “just for fun”? We need professional help.

use std::collections::HashSet;

/// Solve Day 14, Part 1
fn solve(input: &HashSet<Point>) -> u32 {
    // Turn that set of impassable points into a `CaveMap`
    let mut cave_map = CaveMap::new(input.clone());

    // We'll drop up to 10K grains of sand. This is overkill, but I'd rather
    // use a `for` loop here instead of a `loop`. Mostly so I have the grain
    // number in the loop without maintaining a separate variable and mutating
    // it each loop.
    for grains in 1..10_000 {
        // When we find the first grain of sand that falls into the infinite
        // abyss, we stop and return the current grain count minus one as
        // the number of grains _before_ this poor soul was lost to the void.
        if let GrainStatus::LostToTheAbyss = cave_map.add_sand() {
            return (grains - 1);
        }
    }

    // If we ever get here, something has gone horribly wrong
    unreachable!()
}

/// This enum represents the status of a grain of sand flowing down from the
/// ceiling. May represent the result of a single step or the entire flow of
/// that grain from start to finish.
#[derive(Debug)]
enum GrainStatus {
    MovedTo(Point),
    StoppedAt(Point),
    LostToTheAbyss,
}

/// Represents the map of our cave. We're keeping up with a set of the points in
/// space that sand can't flow through in `obstacles`, the point where the sand
/// enters the map in `entrypoint`, and the y-index of the lowest point containing
/// rock in `depth`. Past that is the timeless void.
#[derive(Debug, Clone)]
struct CaveMap {
    obstacles: HashSet<Point>,
    entrypoint: Point,
    depth: u32,
}

impl CaveMap {
    /// Create a new `CaveMap` from a set of points representing impassable points
    /// in the cave (for sand).
    fn new(obstacles: HashSet<Point>) -> Self {
        // Find the lowest y-coordinate for any rock
        let depth = obstacles
            .iter()
            .map(|point| point.1)
            .max()
            .unwrap_or_default();

        // Could have been a constant...
        let entrypoint = Point(500, 0);

        CaveMap {
            obstacles,
            entrypoint,
            depth,
        }
    }

    /// Add one grain of sand to the map and follow it as it flows down. Returns
    /// the final status of the grain.
    fn add_sand(&mut self) -> GrainStatus {
        let mut sand = self.entrypoint; // Sand flows in from here

        // Infinite loop!!! It'll stop eventually (we hope).
        loop {
            // Try to flow the grain of sand down one step
            let sand_flow = self.try_move_sand(sand);

            // Do different things depending on what happened when the grain of sand
            // attempted to move down one step.
            match sand_flow {
                // If the grain moved to a new point, update the grain and keep going
                GrainStatus::MovedTo(point) => sand = point,

                // If the grain stopped moving, add it as an obstacle to the cave
                // and break the loop, returning this final status of the grain.
                GrainStatus::StoppedAt(point) => {
                    self.obstacles.insert(point);
                    break sand_flow;
                }

                // If the grain of sand is now tumbling through the dark, slowly
                // forgetting what the sun looks like, break the loop and return
                // this depressing (for the grain of sand) result.
                GrainStatus::LostToTheAbyss => break sand_flow,
            }
        }
    }

    /// Try to move a grain of sand from it's current position downwards.
    fn try_move_sand(&self, sand: Point) -> GrainStatus {
        // A grain of sand can try to move down, down-left, and down-right, in
        // that order.
        let offsets = [Offset(0, 1), Offset(-1, 1), Offset(1, 1)];

        // Try each step in order...
        for offset in offsets {
            // The position that we want the grain of sand to take
            let try_pos = sand + offset;

            // If there's an obstacle there, then try moving another direction
            if self.obstacles.contains(&try_pos) {
                continue;
            }

            // If we're at the y-coordinate representing the depth, then we know
            // there is no hope for the grain of sand and it will spin down into
            // darkness. Return this status.
            if sand.1 >= self.depth {
                return GrainStatus::LostToTheAbyss;
            }

            // If the grain were able to move to the new position, return that result.
            return GrainStatus::MovedTo(try_pos);
        }

        // If all three directions were tried and failed, this grain can go no
        // further. Return that status.
        GrainStatus::StoppedAt(sand)
    }
}

That poor, sacrificial grain of sand. Guess we’ll be joining him soon…

Part Two - Don’t Look Down

Or, actually, maybe not? Turns out we neglected to map the floor we’re currently standing on. Just, wow. Well, I guess we got all worked up for nothing, huh? Oh, wait, we’re on the floor all the sand is flowing down to! Better count how many grains of sand can fit in here!

use std::collections::{HashSet, VecDeque};

/// Solve Day 14, Part 2
fn solve(input: &Input) -> Output {
    // Turn that set of impassable points into a `CaveMap`
    let cave_map = CaveMap::new(input.clone());

    // Now turn that `CaveMap` into a `FillMap` to determine how
    // much sand it takes to fill the pile.
    let mut fill_map = FillMap::from(cave_map);

    // Pour sand into the cave until it fills up to the entrypoint
    // and report the number of grains it took to do so.
    fill_map.sand_capacity().into()
}

/// A slight variation on the `CaveMap`. Mostly using a new struct for different
/// behaviors more than different data types.
#[derive(Debug, Clone)]
struct FillMap {
    obstacles: HashSet<Point>,
    entrypoint: Point,
    depth: u32,
}

impl FillMap {
    /// Unpack a `CaveMap` into a `FillMap`
    fn from(grid_map: CaveMap) -> Self {
        // Get the attributes from the `CaveMap`
        let CaveMap {
            obstacles,
            entrypoint,
            depth,
        } = grid_map;

        // Adjust the depth to represent the floor. Hey, look, there's that grain of
        // sand we thought was gone forever, breathing a huge sigh of relief. Good
        // for him!
        let depth = depth + 2;

        // Now it's a `FillMap`!
        FillMap {
            obstacles,
            entrypoint,
            depth,
        }
    }

    /// From a given Point, return an array indicating which points a grain of sand
    /// can flow into (e.g., that aren't blocked by an obstacle or the floor).
    fn get_neighbors(&self, point: Point) -> [Option<Point>; 3] {
        // The same three potential moves as the first part
        let offsets = [Offset(0, 1), Offset(-1, 1), Offset(1, 1)];

        // Array to hold the neighbors that can be moved to
        let mut neighbors = [None; 3];

        // For each possible offset...
        for (idx, offset) in offsets.iter().enumerate() {
            // The position we might move to.
            let try_pos = point + *offset;

            // If there's an obstacle there, skip it. Can't move there.
            if self.obstacles.contains(&try_pos) {
                continue;
            }

            // If there's floor there, skip it. Can't move there.
            if try_pos.1 >= self.depth {
                continue;
            }

            // Otherwise, we can move there. Add this point to our neighbors array.
            neighbors[idx] = Some(try_pos);
        }

        // Return the list of neighbors
        neighbors
    }

    /// Calculate the number of sand grains it'll take to fill in the pile and
    /// block off the entrypoint. Using Dijkstra's Algorithm! Nah, just kidding,
    /// it's a breadth-first search.
    fn sand_capacity(&self) -> u32 {
        let mut queue = VecDeque::from([self.entrypoint]);
        let mut visited = HashSet::new();
        let mut counted = 0; // Keep up with the number of grains

        // So long as we've got positions to try moving _from_...
        while let Some(point) = queue.pop_back() {
            // If we've visited this space before, skip it. Been here, done that.
            if visited.contains(&point) {
                continue;
            }
            visited.insert(point); // Mark `point` as visited
            counted += 1; // Count this grain of sand

            // For each reachable neighbor point from the current point
            for neighbor in self.get_neighbors(point).iter().flatten() {
                // If we've visited that point before, skip it.
                if visited.contains(neighbor) {
                    continue;
                }

                // Add that point to the list of points to visit
                queue.push_front(*neighbor);
            }
        }

        counted // Return the number of grains of sand we counted
    }
}

Well, given that this problem gives us a map and asks us to fill in a space with some movement rules, we can actually use a breadth-first search instead of trying to simulate each grain of sand one at a time. This basically just means simulating a lot of grains of sand all at once, really, but it’s neat that it works this way.

Wrap Up

Today was a blast! It had everything: iterators, nom parsing, enums, multiple kinds of structs, and endless void, a waterfall, and a graph search algorithm that, while not immediately obvious, is actually a really good solution! Looks like Advent of Code peaked early this year. I do really like the way we can create custom iterators in Rust. After using Julia for past years, I appreciate just how much more intuitive it is to have a struct with nicely named fields to store your iterator state in instead of some nebulous data structure being passed in and out of an iterator function. Given that they both work similarly, I find I prefer the Rust syntax overall. On a strange note, I noticed that my input had a bunch of duplication in it today. It turned out not to really matter since I was storing all the “rocks” in a HashSet which de-duplicated everything anyway, but this may have thrown a curveball to other approaches. If you’re having trouble, maybe that’s part of it. Either way, I hope you’re having as much fun as I am, and I’ll see you tomorrow!

Advent of Code 2022 - Day 13

Tue, 13 Dec 2022 00:00:00 +0000

Day 13 - Distress Signal

Find the problem description HERE.

The Input - Yo Dawg, I Heard You Like Packets

I won’t lie to you, I really don’t like dealing with recursive data structures in Rust. It probably stems from the fact that one of the early coding puzzles I cleverly decided to leverage to learn the language involved flattening arbitrarily nested lists. The puzzle itself was no big deal, but figuring out how to have arbitrarily nested lists was probably more than I was ready for at the time. Which is why I was so surprised at how readily nom was able to handle these recursive packets!

/// Represnts a Packet. Packet data consists of lists and integer (that's what the
/// puzzle says, anyway).
#[derive(Debug, Clone, PartialEq, Eq)]
enum Packet {
    Integer(u8),
    List(Vec<Packet>),
}

/// Represents a pair of packets. Riveting stuff!
#[derive(Debug, Clone)]
struct PacketPair(Packet, Packet);

/// Here's where the magic happens. This module wraps the parsers for the list of
/// packet pairs presented in the input.
mod parser {
    use super::*;
    use anyhow::{anyhow, Result};
    use nom::{
        branch::alt,
        bytes::complete::tag,
        character::complete::{newline, u8},
        combinator::map,
        multi::{separated_list0, separated_list1},
        sequence::{delimited, separated_pair},
        Finish, IResult,
    };

    /// Nom parser for "2" -> Packet::Integer(2)
    fn integer(s: &str) -> IResult<&str, Packet> {
        map(u8, Packet::Integer)(s)
    }

    /// This is where the recursion happens. This parser parses lists of
    /// packet information into their appropriate packet representation.
    /// Parses all of the following:
    ///   - "[]" -> Packet::List([])
    ///   - "[5]" -> Packet::List([Packet::Integer(5)])
    ///   - "[1, 2]" -> Packet::List([Packet::Integer(1), Packet::Integer(2)])
    ///   - "[1, [2]]" -> Packet::List([Packet::Integer(1), Packet::List([Packet::Integer(2)])])
    fn list(s: &str) -> IResult<&str, Packet> {
        let list_contents = separated_list0(tag(","), packet);
        map(delimited(tag("["), list_contents, tag("]")), Packet::List)(s)
    }

    /// Packet data consists of lists and integers. This parser will parse a `Packet`
    /// from a list or things or from a single integer.
    fn packet(s: &str) -> IResult<&str, Packet> {
        alt((integer, list))(s)
    }

    /// Parses two packets separated by a newline into a `PacketPair`
    fn packet_pair(s: &str) -> IResult<&str, PacketPair> {
        let (s, (first, second)) = separated_pair(packet, newline, packet)(s)?;
        Ok((s, PacketPair(first, second)))
    }

    /// Parses a list of packet pairs separated by an empty line into a `Vec<PacketPair>`
    pub fn parse(s: &str) -> Result<Vec<PacketPair>> {
        let result = separated_list1(tag("\n\n"), packet_pair)(s).finish();
        let (_, pair_list) = result.map_err(|e| anyhow!("{e}"))?;
        Ok(pair_list)
    }
}

const INPUT: &str = include_str!("../../input/13/input.txt");

/// Parse that input!
fn read() -> Vec<PacketPair> {
    parser::parse(INPUT).unwrap()
}

Three functions with four total lines for parsing a single line into a nested Packet. Not too shabby!

Part One - Peter Piper Picked a Pair of Pretty Packets

Well, well, well. Looks like those elves who left us in the river are in need of some help. Probably mis-labeled the snacks or something else equally disastrous. Well, as it turns out, we have exactly the right pair of traits in Rust to deal with this sort of situation: Ord and PartialOrd.

use std::cmp::Ordering;

/// Solve Day 13, Part 1
fn solve(input: &Vec<PacketPair>) -> u32 {
    let mut total = 0; // The total index value of proper sorted pairs

    // For each pair of packets...
    for (idx, packet_pair) in input.iter().enumerate() {
        // If it's not sorted correctly, skip.
        if !packet_pair.is_sorted() {
            continue;
        }

        // Otherwise, add the value of its index to the total
        total += (idx as u32) + 1; // Packets are 1-indexed
    }
    total
}

impl PacketPair {
    /// Indicates if the first packet in a pair is less than the second
    /// packet in the pair.
    fn is_sorted(&self) -> bool {
        let Self(first, second) = self;
        first < second
    }
}

/// Partial ordering for `Packet`s. Defining this would be enough to use
/// `Packet` < `Packet`, but we won't be able to do a full sort without
/// implementing `Ord` as well.
impl PartialOrd for Packet {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

/// Defines the result of comparing one `Packet` to another, used for ordinal
/// comparisons and sorting. Returns an enum that indicates whether `self` is
/// less than, greater than, or even equal to `other`.
impl Ord for Packet {
    fn cmp(&self, other: &Self) -> Ordering {
        use Packet::*; // For syntax
        match (self, other) {
            // When comparing two packet integers, just compare them by value
            (Integer(i1), Integer(i2)) => i1.cmp(i2),

            // When comparing a packet integer to a packet list, convert the integer
            // to a single item list and compare the two lists.
            (Integer(i), List(_)) => List(vec![Integer(*i)]).cmp(other),
            (List(_), Integer(i)) => self.cmp(&List(vec![Integer(*i)])),

            // When comparing two lists, compare item by item and return the first
            // result where the two items aren't equal. If one list has more items
            // than another and all the values up to the length of the shortest list
            // are equal, then we compare the length of the lists.
            (List(l1), List(l2)) => {
                for (first, second) in l1.iter().zip(l2.iter()) {
                    let result = first.cmp(second);
                    let Ordering::Equal = result else { return result; };
                }
                l1.len().cmp(&l2.len())
            }
        }
    }
}

Really, it’s mostly a matter of implementing the sorting rules as written. Granted, they are written a bit confusingly (for me, at least), but the examples help make it clear what we need to do. Once we know how to handle the three different situations, we implement those rules, and voila!

Part Two - The Dividing Line(s)

Looks like implementing those traits was exactly the right call. Since we can sort Packets without any extra work, all we need to do is flatten our list of packet pairs, add the dividers, and sort. Nice.

/// Solve Day 13, Part 2
fn solve(input: &Vec<PacketPair>) -> u32 {
    use Packet::*; // For syntax

    // Define the two divider packets and put them in an array to add them
    // to the list of all the packets.
    let divider1 = List(vec![List(vec![Integer(2)])]);
    let divider2 = List(vec![List(vec![Integer(6)])]);
    let dividers = [divider1, divider2];

    // Flatten all the pairs of packets into a list of packets with the two
    // divider packets added to the end.
    let mut all_packets = input
        .iter()
        .cloned()
        .flatten()
        .chain(dividers.iter().cloned())
        .collect::<Vec<_>>();

    // Sort all the packets! No need to do any more work than that, since
    // by implementing Ord and PartialOrd, we've done all we need to
    // sort them.
    all_packets.sort_unstable();

    // Find the indices of the two divider packets and return their product.
    let mut total = 1;
    for (idx, packet) in all_packets.iter().enumerate() {
        if dividers.contains(packet) {
            total *= (idx as u32) + 1;
        }
    }
    total
}

// It's easier to flatten the packet pairs into a 1D list when we can
// iterate over the two packets contained in them.
impl IntoIterator for PacketPair {
    type Item = Packet;
    type IntoIter = std::array::IntoIter<Self::Item, 2>;

    fn into_iter(self) -> Self::IntoIter {
        let PacketPair(first, second) = self;
        [first, second].into_iter()
    }
}

We could probably have done without the gnarly iterator chain to flatten the pairs, but I kind of like iterator chains. They remind me of pipes in R and Julia, which I’m a big fan of.

Wrap Up

Today represents the first day where I really felt like using nom made solving the puzzle easier. Frankly, I was a bit surprised when my initial attempt worked flawlessly. I just knew there would be something confusing in recursively parsing those packets, but it really just came down to writing rules and having the parser follow them. Beyond that, the Rust trait system really provided an ergonomic experience for solving this one. All in all, this was a puzzle that seemed almost designed for the language and approach I’ve been taking this year. About time! Let’s see what tomorrow brings.