ps. look out for all my other solutions for Advent of Code challenges here.
See details of the challenge here.
Today’s input looks like this:
root@ebhq-gridcenter# df -h
Filesystem Size Used Avail Use%
/dev/grid/node-x0-y0 87T 71T 16T 81%
/dev/grid/node-x0-y1 93T 72T 21T 77%
/dev/grid/node-x0-y2 87T 67T 20T 77%
/dev/grid/node-x0-y3 89T 65T 24T 73%
/dev/grid/node-x0-y4 93T 67T 26T 72%
Of the information presented to us we only need the x & y position of the node, its size and amount of space used. Everything else can either be derived from these or are not needed for this challenge.
For part 1 of the challenge, if we sort the array of nodes by the amount of available space in descending order, then for each of the elements we only need to iterate through the sorted array for as long as the available space is >= the used space of the current node. Hence reducing the average time complexity from O(n2) to O(n * log n).
Now that you have a better understanding of the grid, it’s time to get to work.
Your goal is to gain access to the data which begins in the node with
y=0and the highest
x(that is, the node in the top-right corner).
For example, suppose you have the following grid:
Filesystem Size Used Avail Use% /dev/grid/node-x0-y0 10T 8T 2T 80% /dev/grid/node-x0-y1 11T 6T 5T 54% /dev/grid/node-x0-y2 32T 28T 4T 87% /dev/grid/node-x1-y0 9T 7T 2T 77% /dev/grid/node-x1-y1 8T 0T 8T 0% /dev/grid/node-x1-y2 11T 7T 4T 63% /dev/grid/node-x2-y0 10T 6T 4T 60% /dev/grid/node-x2-y1 9T 8T 1T 88% /dev/grid/node-x2-y2 9T 6T 3T 66%
In this example, you have a storage grid
3nodes wide and
3nodes tall. The node you can access directly,
node-x0-y0, is almost full. The node containing the data you want to access,
node-x2-y0(because it has
y=0and the highest
xvalue), contains 6 terabytes of data – enough to fit on your node, if only you could make enough space to move it there.
node-x1-y1looks like it has enough free space to enable you to move some of this data around. In fact, it seems like all of the nodes have enough space to hold any node’s data (except
node-x0-y2, which is much larger, very full, and not moving any time soon). So, initially, the grid’s capacities and connections look like this:
( 8T/10T) -- 7T/ 9T -- [ 6T/10T] | | | 6T/11T -- 0T/ 8T -- 8T/ 9T | | | 28T/32T -- 7T/11T -- 6T/ 9T
The node you can access directly is in parentheses; the data you want starts in the node marked by square brackets.
In this example, most of the nodes are interchangable: they’re full enough that no other node’s data would fit, but small enough that their data could be moved around. Let’s draw these nodes as
.. The exceptions are the empty node, which we’ll draw as
_, and the very large, very full node, which we’ll draw as
#. Let’s also draw the goal data as
G. Then, it looks like this:
(.) . G . _ . # . .
The goal is to move the data in the top right,
G, to the node in parentheses. To do this, we can issue some commands to the grid and rearrange the data:
- Move data from
node-y1-x1, leaving node
(.) _ G . . . # . .
- Move the goal data from
(.) G _ . . . # . .
- At this point, we’re quite close. However, we have no deletion command, so we have to move some more data around. So, next, we move the data from
(.) G . . . _ # . .
- Move the data from
(.) G . . _ . # . .
- Move the data from
(.) G . _ . . # . .
- Next, we can free up space on our node by moving the data from
(_) G . . . . # . .
- Finally, we can access the goal data by moving the it from
(G) _ . . . . # . .
7steps, we’ve accessed the data we want. Unfortunately, each of these moves takes time, and we need to be efficient:
What is the fewest number of steps required to move your goal data to
If you visualize the grid then the solution becomes pretty clear and one that we can actually work out by hand.
Here, the target node is marked as red, the empty node green (which is initially at position (7, 17)), and the very large, very full nodes are marked as black. We want to move the empty node all the way to (35, 0) so we can start moving the target node at (36, 0) horizontally towards (0, 0).
We can again use the Level Order Tree Traversal approach we have seen so many times this AOC for the first part. First, let’s transform the Node into a 2D array first to make our task easier.
The trick for the traversal part of the problem is to avoid passing through the same coordinate more than once, a problem that can be easily rectified with a cache of positions that we have already passed through.
Once the empty node is at (35, 0) we can commence the second part of the problem – to move the data in the target node to (0, 0). Every time we move the data to the empty node on the left, we’ll have to move the empty node in front of it again, which means going down, left, left and then up, so that means a total of 5 moves for every step towards (0, 0). Except, when the data is at (1, 0), which requires only one move.
Which means, there’s a total of 5 * 35 + 1 move left ONCE we have move the empty node to (35, 0).
In case you’re wondering why I left out the “+ 1” on line 33, it’s because the path that’s returned by findPaths includes the starting position (7, 17), so really line 33 should have read let part2 = path.Length – 1 + 35 * 5 + 1
- Day 22 challenge description
- Advent of Code 2015
- Solution for Day 21
- All my F# solutions for Advent of Code
- Github repo
Enjoy what you’re reading? Subscribe to my newsletter and get more content on AWS and serverless technologies delivered straight to your inbox.
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, design patterns and best practices.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong