1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

//! # Day 20: Particle Swarm
//!
//! Suddenly, the GPU contacts you, asking for help. Someone has asked it to simulate **too many
//! particles**, and it won't be able to finish them all in time to render the next frame at this
//! rate.
//!
//! It transmits to you a buffer (your puzzle input) listing each particle in order (starting with
//! particle `0`, then particle `1`, particle `2`, and so on). For each particle, it provides the
//! `X`, `Y`, and `Z` coordinates for the particle's position (`p`), velocity (`v`), and
//! acceleration (`a`), each in the format `<X,Y,Z>`.
//!
//! Each tick, all particles are updated simultaneously. A particle's properties are updated in the
//! following order:
//!
//! - Increase the `X` velocity by the `X` acceleration.
//! - Increase the `Y` velocity by the `Y` acceleration.
//! - Increase the `Z` velocity by the `Z` acceleration.
//! - Increase the `X` position by the `X` velocity.
//! - Increase the `Y` position by the `Y` velocity.
//! - Increase the `Z` position by the `Z` velocity.
//!
//! Because of seemingly tenuous rationale involving [z-buffering], the GPU would like to know which
//! particle will stay closest to position `<0,0,0>` in the long term. Measure this using the
//! [Manhattan distance], which in this situation is simply the sum of the absolute values of a
//! particle's `X`, `Y`, and `Z` position.
//!
//! For example, suppose you are only given two particles, both of which stay entirely on the X-axis
//! (for simplicity). Drawing the current states of particles `0` and `1` (in that order) with an
//! adjacent a number line and diagram of current `X` positions (marked in parentheses), the
//! following would take place:
//!
//! ```txt
//! p=< 3,0,0>, v=< 2,0,0>, a=<-1,0,0>    -4 -3 -2 -1  0  1  2  3  4
//! p=< 4,0,0>, v=< 0,0,0>, a=<-2,0,0>                         (0)(1)
//!
//! p=< 4,0,0>, v=< 1,0,0>, a=<-1,0,0>    -4 -3 -2 -1  0  1  2  3  4
//! p=< 2,0,0>, v=<-2,0,0>, a=<-2,0,0>                      (1)   (0)
//!
//! p=< 4,0,0>, v=< 0,0,0>, a=<-1,0,0>    -4 -3 -2 -1  0  1  2  3  4
//! p=<-2,0,0>, v=<-4,0,0>, a=<-2,0,0>          (1)               (0)
//!
//! p=< 3,0,0>, v=<-1,0,0>, a=<-1,0,0>    -4 -3 -2 -1  0  1  2  3  4
//! p=<-8,0,0>, v=<-6,0,0>, a=<-2,0,0>                         (0)
//! ```
//!
//! At this point, particle `1` will never be closer to `<0,0,0>` than particle `0`, and so, in the
//! long run, particle `0` will stay closest.
//!
//! **Which particle will stay closest to position `<0,0,0>`** in the long term?
//!
//! [z-buffering]: https://en.wikipedia.org/wiki/Z-buffering
//! [Manhattan distance]: https://en.wikipedia.org/wiki/Taxicab_geometry

use anyhow::Result;

pub const INPUT: &str = include_str!("d20.txt");

pub fn solve_part_one(input: &str) -> Result<i64> {
    Ok(0)
}

pub fn solve_part_two(input: &str) -> Result<i64> {
    Ok(0)
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn part_one() {}

    #[test]
    fn part_two() {}
}