aoc/year2022/
day07.rs

1//! # No Space Left On Device
2//!
3//! Some up-front analysis of the input data helps us develop an efficient solving algorithm (this
4//! is a regular theme in Advent of Code!). Looking at the directory commands shows 2 key insights:
5//! * We never return to a previously visited directory
6//! * Directory traversal is only up or down in steps of one.
7//!
8//! This allows us to infer:
9//! * `$ ls` lines contain no useful information and can be ignored.
10//! * `dir foo` lines also contain no useful information and can be ignored.
11//! * Only the size in `12345 foo.bar` file listings is useful.
12//! * `cd foo` commands imply a "down" direction, but the name is not needed and can be ignored.
13//! * `cd ..` commands imply that we are finished with the current directory.
14//!
15//! For my input data this meant that 58% of it was unnecessary! Our algorithm will be:
16//! * If we encounter a file listing then add its size to the current running total.
17//! * Create a `vec` to function as a stack of incomplete directories. Anytime we encounter a
18//!   `cd foo` command, then we push the size of the current directory to this stack to save for
19//!   later, then reset our running total to 0.
20//! * Create a second `vec` to store the sizes of completed directories. Anytime we encounter
21//!   a `cd ..` then we can "complete" the current directory and add its size to this list. To find
22//!   our new running total we then pop the previous unfinished directory off the stack
23//!   (and this is the neat part) *add* the size of the just completed directory, since we know
24//!   that it must have been a child of the directory at the top of the stack.
25//!
26//!   Note that the end of the file is essentially an sequence of implicit `cd ..` commands
27//!   all the way to the root. Another nice side effect is that the root directory is always the
28//!   last element in our `vec`.
29//!
30//! For example, the sample input reduces to essentially only:
31//!
32//! `down 14848514 8504156 down 29116 2557 62596 down 584 up up down 4060174 8033020 5626152 7214296 [implicit up up]`
33//!
34//! This means that the algorithm is extremely efficient and the data structures are very
35//! straightforward. For example there's no need to store the current path names, or to recursively
36//! update upwards whenever a file is encountered.
37use crate::util::parse::*;
38
39/// Tokenize the input and return a `vec` of directory sizes.
40pub fn parse(input: &str) -> Vec<u32> {
41    let mut cd = false;
42    let mut total = 0;
43    let mut stack = Vec::new();
44    let mut sizes = Vec::new();
45
46    for token in input.split_ascii_whitespace() {
47        if cd {
48            if token == ".." {
49                sizes.push(total);
50                total += stack.pop().unwrap();
51            } else {
52                stack.push(total);
53                total = 0;
54            }
55            cd = false;
56        } else if token == "cd" {
57            cd = true;
58        } else if token.as_bytes()[0].is_ascii_digit() {
59            total += token.unsigned::<u32>();
60        }
61    }
62
63    while !stack.is_empty() {
64        sizes.push(total);
65        total += stack.pop().unwrap();
66    }
67
68    sizes
69}
70
71/// Sum all directories 100,000 bytes or less.
72pub fn part1(input: &[u32]) -> u32 {
73    input.iter().filter(|&&x| x <= 100_000).sum()
74}
75
76/// Find the smallest directory that can be deleted to free up the necessary space.
77pub fn part2(input: &[u32]) -> u32 {
78    let root = input.last().unwrap();
79    let needed = 30_000_000 - (70_000_000 - root);
80    *input.iter().filter(|&&x| x >= needed).min().unwrap()
81}