Document year 2015 day 1-2

Author: maneatingape

src/lib.rs

@@ -75,7 +75,7 @@ pub mod year2021 {
     pub mod day25;
 }
 
-/// # Try to enjoy a well deserved vacation, what could go wrong?
+/// # What could go wrong trying to enjoy a well deserved vacation?
 pub mod year2020 {
     pub mod day01;
     pub mod day02;

src/year2020/day01.rs

@@ -1,3 +1,17 @@
+//! # Report Repair
+//!
+//! The straightforward approach is to compare every possible pair of elements for part 1 and
+//! every possible triple for part 2. This would have `O(n²)` and `O(n³)`time complexity respectively.
+//!
+//! We can do better with `O(n)` complexity for part 1 and `O(n²)` for part 2, with an shared
+//! upfront cost of `O(logn)`.
+//!
+//! First sort the slice in ascending order. Then maintain two pointers starting at the beginning
+//! and end of the slice. If the sum if greater then decrement the end pointer. If the sum is less
+//! decrement the end pointer. If equal then return the product of the pair.
+//!
+//! Part 2 reuses the pair finding logic, finding the third element by stepping through the slice
+//! one by one and adjusting the target total.
 use crate::util::parse::*;
 use std::cmp::Ordering::*;
 

src/year2020/day02.rs

@@ -1,3 +1,14 @@
+//! # Password Philosophy
+//!
+//! Parsing the rules upfront allows both part 1 and part 2 to be solved in a straightforward manner.
+//!
+//! There's no need to first convert the input into lines since we know that each rule has 4 parts.
+//! Instead we use the [`split`] method with a slice of delimeters to break the input into
+//! an `Iterator` of tokens, then use our utility [`chunk`] method to group the tokens into an
+//! array of size 4.
+//!
+//! [`split`]: slice::split
+//! [`chunk`]: crate::util::iter
 use crate::util::iter::*;
 use crate::util::parse::*;