From 3e10f187cedbb8607a6774299c07cb67b5bde69e Mon Sep 17 00:00:00 2001 From: maneatingape <44142177+maneatingape@users.noreply.github.com> Date: Fri, 17 Oct 2025 22:32:57 +0100 Subject: [PATCH] Comment linting --- CONTRIBUTING.md | 2 +- src/util/grid.rs | 4 ++-- src/util/math.rs | 2 +- src/util/parse.rs | 4 ++-- src/util/thread.rs | 6 +++--- src/year2015/day07.rs | 2 +- src/year2015/day23.rs | 2 +- src/year2015/day25.rs | 2 +- src/year2016/day12.rs | 2 +- src/year2016/day19.rs | 6 +++--- src/year2016/day23.rs | 2 +- src/year2016/day24.rs | 2 +- src/year2017/day03.rs | 2 +- src/year2018/day06.rs | 2 +- src/year2018/day09.rs | 4 ++-- src/year2018/day15.rs | 2 +- src/year2018/day22.rs | 2 +- src/year2019/day16.rs | 2 +- src/year2019/day17.rs | 2 +- src/year2019/day25.rs | 4 ++-- src/year2020/day07.rs | 4 ++-- src/year2020/day20.rs | 6 +++--- src/year2020/day24.rs | 4 ++-- src/year2021/day18.rs | 2 +- src/year2022/day01.rs | 2 +- src/year2022/day07.rs | 2 +- src/year2022/day12.rs | 2 +- src/year2022/day16.rs | 2 +- src/year2022/day19.rs | 6 +++--- src/year2023/day09.rs | 2 +- src/year2023/day12.rs | 2 +- src/year2023/day17.rs | 4 ++-- src/year2023/day23.rs | 4 ++-- src/year2024/day09.rs | 2 +- src/year2024/day12.rs | 2 +- src/year2024/day16.rs | 2 +- src/year2024/day17.rs | 2 +- src/year2024/day23.rs | 2 +- 38 files changed, 54 insertions(+), 54 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a08a0b1e..bfff2bd5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,7 +3,7 @@ I hope that you've enjoyed reading these solutions as much as I enjoyed writing them. They're pretty fast and clean...but can you make them even *faster and cleaner*? -If you've made an improvement then please +If you've made an improvement, then please [open a pull request](https://github.com/maneatingape/advent-of-code-rust/compare). Contributions are encouraged and valued. ❤️ diff --git a/src/util/grid.rs b/src/util/grid.rs index 9cae73c1..f23e05e8 100644 --- a/src/util/grid.rs +++ b/src/util/grid.rs @@ -18,8 +18,8 @@ //! //! A convenience [`parse`] method creates a `Grid` directly from a 2 dimensional set of //! ASCII characters, a common occurrence in Advent of Code inputs. The [`same_size_with`] function -//! creates a grid of the same size, that can be used for in BFS algorithms for tracking visited -//! location or for tracking cost in Dijkstra. +//! creates a grid of the same size that can be used in BFS algorithms for tracking visited +//! locations or for tracking cost in Dijkstra. //! //! [`Point`]: crate::util::point //! [`parse`]: Grid::parse diff --git a/src/util/math.rs b/src/util/math.rs index 7fa2056d..0119b723 100644 --- a/src/util/math.rs +++ b/src/util/math.rs @@ -6,7 +6,7 @@ //! //! * [Least common multiple](https://en.wikipedia.org/wiki/Least_common_multiple) //! -//! * [Modular exponentation](https://en.wikipedia.org/wiki/Modular_exponentiation). +//! * [Modular exponentiation](https://en.wikipedia.org/wiki/Modular_exponentiation). //! Calculates bᵉ mod m efficiently using //! [exponentiation by squaring](https://en.wikipedia.org/wiki/Exponentiation_by_squaring). //! diff --git a/src/util/parse.rs b/src/util/parse.rs index ec938902..b24fe34c 100644 --- a/src/util/parse.rs +++ b/src/util/parse.rs @@ -8,8 +8,8 @@ //! ``` //! //! This module provides two [`&str`] extension methods [`iter_signed`] and [`iter_unsigned`]. The -//! reason for the separate methods is that some Advent of Code inputs contains the `-` character -//! as a delimeter and this would cause numbers to be incorrectly parsed as negative. +//! reason for the separate methods is that some Advent of Code inputs contain the `-` character +//! as a delimiter and this would cause numbers to be incorrectly parsed as negative. //! //! [`iter_unsigned`]: ParseOps::iter_unsigned //! [`iter_signed`]: ParseOps::iter_signed diff --git a/src/util/thread.rs b/src/util/thread.rs index 149e7012..262bb66e 100644 --- a/src/util/thread.rs +++ b/src/util/thread.rs @@ -1,6 +1,6 @@ //! Utility methods to spawn a number of //! [scoped](https://doc.rust-lang.org/stable/std/thread/fn.scope.html) -//! threads equals to the number of cores on the machine. Unlike normal threads, scoped threads +//! threads equal to the number of cores on the machine. Unlike normal threads, scoped threads //! can borrow data from their environment. use std::sync::atomic::{AtomicBool, AtomicU32, AtomicUsize, Ordering::Relaxed}; use std::thread::*; @@ -31,7 +31,7 @@ where /// Spawns `n` scoped threads that each receive a /// [work stealing](https://en.wikipedia.org/wiki/Work_stealing) iterator. /// Work stealing is an efficient strategy that keeps each CPU core busy when some items take longer -/// than other to process, used by popular libraries such as [rayon](https://github.com/rayon-rs/rayon). +/// than others to process, used by popular libraries such as [rayon](https://github.com/rayon-rs/rayon). /// Processing at different rates also happens on many modern CPUs with /// [heterogeneous performance and efficiency cores](https://en.wikipedia.org/wiki/ARM_big.LITTLE). pub fn spawn_parallel_iterator(items: &[T], f: F) -> Vec @@ -43,7 +43,7 @@ where let threads = threads(); let size = items.len().div_ceil(threads); - // Initially divide work as evenly as possible amongst each worker thread. + // Initially divide work as evenly as possible among each worker thread. let workers: Vec<_> = (0..threads) .map(|id| { let start = (id * size).min(items.len()); diff --git a/src/year2015/day07.rs b/src/year2015/day07.rs index 386ab854..97bb7782 100644 --- a/src/year2015/day07.rs +++ b/src/year2015/day07.rs @@ -1,7 +1,7 @@ //! # Some Assembly Required //! //! To obtain the result we recursively compute the inputs starting at gate `a` and working -//! backwards. To make things faster we memoize the result of each wire in a cache, so that each +//! backward. To make things faster we memoize the result of each wire in a cache, so that each //! wire is computed at most once. //! //! For part two we pre-seed the value of `b` in the cache with the result from part one then diff --git a/src/year2015/day23.rs b/src/year2015/day23.rs index 5710986c..c28d0efd 100644 --- a/src/year2015/day23.rs +++ b/src/year2015/day23.rs @@ -4,7 +4,7 @@ //! [3n + 1 sequence](https://en.wikipedia.org/wiki/Collatz_conjecture) //! for one of two different numbers chosen depending on whether `a` is 0 or 1. //! -//! The code fast enough to emulate directly without needing any understanding of what it's doing. +//! The code is fast enough to emulate directly without needing any understanding of what it's doing. use crate::util::parse::*; pub enum Op { diff --git a/src/year2015/day25.rs b/src/year2015/day25.rs index fd5cadc0..a9c98cf7 100644 --- a/src/year2015/day25.rs +++ b/src/year2015/day25.rs @@ -22,7 +22,7 @@ //! //! Starting at the chosen number 12 and moving diagonally upwards to the right we intersect //! the top row at column `column + row - 1 = 2 + 4 - 1 = 5`. This gives the triangular number -//! `5 * (5 + 1) / 2 = 15`. Then we count backwards by `row` elements to get the one less +//! `5 * (5 + 1) / 2 = 15`. Then we count backward by `row` elements to get the one less //! zero based based index `15 - 4 = 11`. //! //! The second part is realizing that the description of the code generation is diff --git a/src/year2016/day12.rs b/src/year2016/day12.rs index 192b5b03..5ef71c10 100644 --- a/src/year2016/day12.rs +++ b/src/year2016/day12.rs @@ -3,7 +3,7 @@ //! This problem is interesting in that the solution is all about *reading* code not writing code. //! //! We could implement a brute force virtual machine without understanding the underlying code -//! but it's much more efficient to analyse the code instead. +//! but it's much more efficient to analyze the code instead. //! //! The first thing we notice is that the following idiom is repeated several times: //! diff --git a/src/year2016/day19.rs b/src/year2016/day19.rs index f1ddad2e..64bf4210 100644 --- a/src/year2016/day19.rs +++ b/src/year2016/day19.rs @@ -2,7 +2,7 @@ //! //! The title is a reference to the [Josephus problem](https://en.wikipedia.org/wiki/Josephus_problem). //! We can solve both parts efficiently in `O(1)` constant storage without needing any -//! auxiliary data strucutres. +//! auxiliary data structures. //! //! ## Part One //! @@ -58,12 +58,12 @@ //! //! Part two is a variant of the problem. We solve in `log(n)` time by working *backwards* //! from the winning elf until we reach the starting number of elves. -//! Starting with the winning elf `a` it must have eliminated its neighbour to the right: +//! Starting with the winning elf `a` it must have eliminated its neighbor to the right: //! //! `a` => `a b` //! //! We then choose the previous elf to the left wrapping around to elf `b` in this case. Elf `b` -//! must have eliminated its neighbour 1 step to the right: +//! must have eliminated its neighbor 1 step to the right: //! //! `a b` => `a b c` //! diff --git a/src/year2016/day23.rs b/src/year2016/day23.rs index 2f9fab8c..562bbc7e 100644 --- a/src/year2016/day23.rs +++ b/src/year2016/day23.rs @@ -3,7 +3,7 @@ //! Like [`Day 12`] this problem is all about *reading* code not writing code. //! //! We could implement a brute force virtual machine without understanding the underlying code -//! but it's much more efficient to analyse the code instead. +//! but it's much more efficient to analyze the code instead. //! //! The first thing we notice is that the following idiom is repeated several times: //! diff --git a/src/year2016/day24.rs b/src/year2016/day24.rs index 85da26b8..d3962d99 100644 --- a/src/year2016/day24.rs +++ b/src/year2016/day24.rs @@ -9,7 +9,7 @@ //! searches starting from each location. //! //! For speed we convert each location into an index, then store the distances between -//! every pair of locations in an vec for fast lookup. Our utility [`permutations`] method uses +//! every pair of locations in a vec for fast lookup. Our utility [`permutations`] method uses //! [Heap's algorithm](https://en.wikipedia.org/wiki/Heap%27s_algorithm) for efficiency, //! modifying the slice in place. //! diff --git a/src/year2017/day03.rs b/src/year2017/day03.rs index eee402e7..fd7f0221 100644 --- a/src/year2017/day03.rs +++ b/src/year2017/day03.rs @@ -19,7 +19,7 @@ //! ------------> //! ``` //! -//! The first component is the horizontal or vertical distance from the centre to the ring, +//! The first component is the horizontal or vertical distance from the center to the ring, //! in this case 2 steps. The second component is the distance from the target number to the //! center of each edge, in this case 2 - 1 = 1. //! diff --git a/src/year2018/day06.rs b/src/year2018/day06.rs index 4ea3645f..0ee3fef4 100644 --- a/src/year2018/day06.rs +++ b/src/year2018/day06.rs @@ -51,7 +51,7 @@ pub fn part1(input: &Input) -> i32 { let mut finite = vec![true; points.len()]; let mut candidates: Vec<(usize, i32, i32)> = Vec::new(); - // Special value for coordinates that are equidistant from nearest neighbour. + // Special value for coordinates that are equidistant from nearest neighbor. let marker = usize::MAX; // Sorts points left to right so that ranges can be merged. diff --git a/src/year2018/day09.rs b/src/year2018/day09.rs index 8ddd80a2..957454e9 100644 --- a/src/year2018/day09.rs +++ b/src/year2018/day09.rs @@ -45,7 +45,7 @@ //! ...<2> 10 5 11 1 12 6 13 3 14 7 15 0 16 8 17 4 18 (19) //! ``` //! -//! For the 20th, 21st and 22nd marbles we re-write the history of the tail then move it backwards. +//! For the 20th, 21st and 22nd marbles we re-write the history of the tail then move it backward. //! //! ```none //! 20th marble @@ -70,7 +70,7 @@ //! It may seem that we need to generate `(last marble / 23)` blocks. However in each block we add //! 37 marbles (2 each for the first 18 marbles and 1 for the 19th) while the marble added to each //! player's score advances `23 - 7 = 16` marbles. This means we only need to generate about -//! `16/37` or `44%` of the total blocks to solve the game deterministcally. This saves both +//! `16/37` or `44%` of the total blocks to solve the game deterministically. This saves both //! processing time and memory storage proportionally. use crate::util::iter::*; use crate::util::parse::*; diff --git a/src/year2018/day15.rs b/src/year2018/day15.rs index cea01fc1..b1ad269d 100644 --- a/src/year2018/day15.rs +++ b/src/year2018/day15.rs @@ -200,7 +200,7 @@ fn fight(input: &Input, elf_attack_power: i32, part_two: bool) -> Option { // Search for neighboring enemies. let mut nearby = attack(&grid, &units, position, kind); - // If no enemy next to unit then move towards nearest enemy in reading order, + // If no enemy next to unit then move toward nearest enemy in reading order, // breaking equal distance ties in reading order. if nearby.is_none() && let Some(next) = double_bfs(input.walls, &units, position, kind) diff --git a/src/year2018/day22.rs b/src/year2018/day22.rs index 302b538c..68d95a94 100644 --- a/src/year2018/day22.rs +++ b/src/year2018/day22.rs @@ -19,7 +19,7 @@ //! can be implemented in Rust using a [`BinaryHeap`]. However the total cost follows a strictly //! increasing order in a constrained range of values, so we can use a much faster //! [bucket queue](https://en.wikipedia.org/wiki/Bucket_queue). The range of the increase is from -//! 0 (moving towards the target and not changing tools) to 7 (staying put and changing tools) +//! 0 (moving toward the target and not changing tools) to 7 (staying put and changing tools) //! requiring 8 buckets total. //! //! [`BinaryHeap`]: std::collections::BinaryHeap diff --git a/src/year2019/day16.rs b/src/year2019/day16.rs index 91250913..a4fc05c8 100644 --- a/src/year2019/day16.rs +++ b/src/year2019/day16.rs @@ -63,7 +63,7 @@ //! We could compute the coefficient using the formula `nᵏ/k!` however this [grows rather large] //! and quickly will overflow even a `u128`. //! -//! However we only need to coefficient modulo 10. [Lucas's theorem] allow us to computer binomial +//! However we only need the coefficient modulo 10. [Lucas's theorem] allows us to compute binomial //! coefficients modulo some prime number. If we compute the coefficients modulo 2 and modulo 5 //! then we can use the [Chinese remainder theorem] to find the result modulo 10. //! diff --git a/src/year2019/day17.rs b/src/year2019/day17.rs index 05e51b3b..8f2b33d1 100644 --- a/src/year2019/day17.rs +++ b/src/year2019/day17.rs @@ -8,7 +8,7 @@ //! //! First we find the complete path with a simple heuristic: //! * Rotate left or right to face the current path segment (a horizontal or vertical line). -//! * Go forwards until we hit the end of the current path segment. +//! * Go forward until we hit the end of the current path segment. //! * If it's a dead end then finish. //! //! Then we look for three patterns that can be repeated in any order to form the whole path. diff --git a/src/year2019/day25.rs b/src/year2019/day25.rs index 5b98f6fb..2a915661 100644 --- a/src/year2019/day25.rs +++ b/src/year2019/day25.rs @@ -118,7 +118,7 @@ fn play_automatically(input: &[i64]) -> String { let changed = current ^ previous; let index = changed.trailing_zeros() as usize; - // Since we start with all items in our possesion, the meaning of bits in the gray code is + // Since we start with all items in our possession, the meaning of bits in the gray code is // reversed. 0 is take an item and 1 is drop an item. if current & changed == 0 { take_item(&mut computer, &inventory[index]); @@ -244,7 +244,7 @@ fn drain_output(computer: &mut Computer) { while let State::Output(_) = computer.run() {} } -// Convert an normal binary number to its Gray Code equivalent +// Convert a normal binary number to its Gray Code equivalent. fn gray_code(n: u32) -> u32 { n ^ (n >> 1) } diff --git a/src/year2020/day07.rs b/src/year2020/day07.rs index e2586d98..65b3134f 100644 --- a/src/year2020/day07.rs +++ b/src/year2020/day07.rs @@ -1,7 +1,7 @@ //! # Handy Haversacks //! -//! A hashtable would be a natural data structure for this problem but is a little slow. -//! To make things faster we implement the hashtable using an array and a combination of three +//! A hash table would be a natural data structure for this problem but is a little slow. +//! To make things faster we implement the hash table using an array and a combination of three //! [perfect hash functions](https://en.wikipedia.org/wiki/Perfect_hash_function) that map from //! each combination of bag descriptions to a unique index. //! diff --git a/src/year2020/day20.rs b/src/year2020/day20.rs index ee3c8ff7..31b61519 100644 --- a/src/year2020/day20.rs +++ b/src/year2020/day20.rs @@ -14,9 +14,9 @@ //! //! ## Part One //! -//! First we calculate the frequency of each edge, both forwards and backwards as tiles can be in -//! any orientation. As there only 2¹⁰ or 1024 possible edge values we can use an array instead of a -//! hashtable for speed, converting the edges into a binary number to index the array. +//! First we calculate the frequency of each edge, both forward and backward as tiles can be in +//! any orientation. As there are only 2¹⁰ or 1024 possible edge values we can use an array instead of a +//! hash table for speed, converting the edges into a binary number to index the array. //! //! This results in 96 values that occur once and 528 values that occur twice. Then for every tile //! we sum the frequency of each edge. Corner tiles will have two edges that only occur once, not diff --git a/src/year2020/day24.rs b/src/year2020/day24.rs index c169f93e..de0bf41c 100644 --- a/src/year2020/day24.rs +++ b/src/year2020/day24.rs @@ -10,8 +10,8 @@ //! a "pull" model where we check the surrounding neighbors of each tile, to a "push" model //! where we update the neighbors of each black tile instead. //! -//! The SIMD alterative approach is much faster, processing 32 lanes at a time. As a further -//! optimisation we skip rows and columns that the active state hasn't reached. The approach +//! The SIMD alternative approach is much faster, processing 32 lanes at a time. As a further +//! optimization we skip rows and columns that the active state hasn't reached. The approach //! is very similar to [`day 11`]. //! //! [`day 17`]: crate::year2020::day17 diff --git a/src/year2021/day18.rs b/src/year2021/day18.rs index 7b0c8cb7..86eb587e 100644 --- a/src/year2021/day18.rs +++ b/src/year2021/day18.rs @@ -186,7 +186,7 @@ fn split(tree: &mut Snailfish) -> bool { /// Calculate the magnitude of a snailfish number in place without using recursion. /// /// This operation is destructive but much faster than using a recursive approach and acceptable -/// as we no longer need the original snailfish number afterwards. +/// as we no longer need the original snailfish number afterward. fn magnitude(tree: &mut Snailfish) -> i32 { for i in (0..31).rev() { if tree[i] == -1 { diff --git a/src/year2022/day01.rs b/src/year2022/day01.rs index b54df768..9d3616c1 100644 --- a/src/year2022/day01.rs +++ b/src/year2022/day01.rs @@ -1,5 +1,5 @@ //! # Calorie Counting -//! Sums groups of numbers separated by blank lines into an `vec` sorted in ascending order. +//! Sums groups of numbers separated by blank lines into a `vec` sorted in ascending order. //! //! Since we don't care what order the highest values are returned in [`select_nth_unstable`] would //! also work, and in theory is a little faster, however the difference was negligible when benchmarking. diff --git a/src/year2022/day07.rs b/src/year2022/day07.rs index 80c09315..34a680bd 100644 --- a/src/year2022/day07.rs +++ b/src/year2022/day07.rs @@ -23,7 +23,7 @@ //! (and this is the neat part) *add* the size of the just completed directory, since we know //! that it must have been a child of the directory at the top of the stack. //! -//! Note that the end of the file is essentially an sequence of implicit `cd ..` commands +//! Note that the end of the file is essentially a sequence of implicit `cd ..` commands //! all the way to the root. Another nice side effect is that the root directory is always the //! last element in our `vec`. //! diff --git a/src/year2022/day12.rs b/src/year2022/day12.rs index c52723f3..72e1dcf6 100644 --- a/src/year2022/day12.rs +++ b/src/year2022/day12.rs @@ -1,6 +1,6 @@ //! # Hill Climbing Algorithm //! -//! Pretty much textbook implementation of a BFS (Breadth First Search). If you're not familar with +//! Pretty much textbook implementation of a BFS (Breadth First Search). If you're not familiar with //! BFS, [this blog post is a great introduction](https://www.redblobgames.com/pathfinding/a-star/introduction.html) //! to the algorithm, plus some others that come in handy for Advent of Code. //! diff --git a/src/year2022/day16.rs b/src/year2022/day16.rs index 507cf4f5..75401606 100644 --- a/src/year2022/day16.rs +++ b/src/year2022/day16.rs @@ -95,7 +95,7 @@ impl Valve<'_> { Valve { name, flow, edges: tokens } } - /// Order valves is descending order of flow then ascending alpabetical order of names. + /// Order valves in descending order of flow then ascending alphabetical order of names. /// This places all non-zero valves at the start followed immediately by valve `AA`. fn cmp(&self, other: &Valve<'_>) -> Ordering { other.flow.cmp(&self.flow).then(self.name.cmp(other.name)) diff --git a/src/year2022/day19.rs b/src/year2022/day19.rs index 52ce75d8..9543245b 100644 --- a/src/year2022/day19.rs +++ b/src/year2022/day19.rs @@ -5,7 +5,7 @@ //! possible combination combined with heuristics to prune those combinations in order to achieve //! a reasonable running time. //! -//! The most import heuristic is: +//! The most important heuristic is: //! * Assume ore is infinite. //! * Always build a clay robot. //! * Check if we can do better than the highest score so far in the remaining time, building @@ -173,7 +173,7 @@ fn dfs(blueprint: &Blueprint, result: &mut u32, time: u32, bots: Mineral, resour /// then check that the estimated maximum possible score is greater than the current high score. /// Additionally we always build a clay robot each turn. /// -/// Since this will always score higher, so we can immediately prune any branch that can't +/// Since this will always score higher, we can immediately prune any branch that can't /// possibly beat the high score. #[inline] fn heuristic( @@ -206,7 +206,7 @@ fn heuristic( } /// "Fast forward" in time until we can build a robot of a particular type. This could possibly -/// by the next minute if we already have enough resources. +/// be the next minute if we already have enough resources. #[inline] fn next( blueprint: &Blueprint, diff --git a/src/year2023/day09.rs b/src/year2023/day09.rs index 1efab396..e7a9bb7b 100644 --- a/src/year2023/day09.rs +++ b/src/year2023/day09.rs @@ -3,7 +3,7 @@ //! We can solve this problem using //! [binomial coefficients](https://en.wikipedia.org/wiki/Binomial_coefficient). //! -//! For example consider an sequence of 3 arbitrary values: +//! For example consider a sequence of 3 arbitrary values: //! //! ```none //! 1st: a b c diff --git a/src/year2023/day12.rs b/src/year2023/day12.rs index 47ad4b88..950109c8 100644 --- a/src/year2023/day12.rs +++ b/src/year2023/day12.rs @@ -212,7 +212,7 @@ where } // Count each subsequent spring. The previous patterns take at least the sum of their size - // and 1 space afterwards so no need to check indices before that. + // and 1 space afterward so no need to check indices before that. let mut start = size + 1; for (row, &size) in springs.iter().enumerate().skip(1) { diff --git a/src/year2023/day17.rs b/src/year2023/day17.rs index 6aa7ff4b..5b320b1a 100644 --- a/src/year2023/day17.rs +++ b/src/year2023/day17.rs @@ -16,7 +16,7 @@ //! //! It's a little more subtle but we also don't need to store 4 directions but only 2, horizontal //! and vertical. The reason is similar to not encoding the number of steps. As we are always -//! implictly going to make a left or right turn immediately, entering a square from the opposite +//! implicitly going to make a left or right turn immediately, entering a square from the opposite //! direction is equivalent. This reduces the storage space and time by half. //! //! To speed things up even further we use a trick. Classic A* uses a generic priority queue that @@ -74,7 +74,7 @@ fn astar(grid: &Grid) -> i32 { let steps = cost[index][direction]; // The heuristic is used as an index into the bucket priority queue. - // Prefer heading towards the bottom right corner, except if we're in the top left + // Prefer heading toward the bottom right corner, except if we're in the top left // quadrant where all directions are considered equally. This prevents a pathological // dual frontier on some inputs that takes twice the time. let heuristic = |x: i32, y: i32, cost: i32| { diff --git a/src/year2023/day23.rs b/src/year2023/day23.rs index 848ed164..76ae3b69 100644 --- a/src/year2023/day23.rs +++ b/src/year2023/day23.rs @@ -63,7 +63,7 @@ //! A row by row dynamic programming approach from top to bottom finds these paths. For each row //! we calculate all possible next rows. Interestingly it turns out that there are only 76 possible //! different rows. Then at each y coordinate we **deduplicate** rows to find the maximum value. -//! This is the most important optimisation as it means that each row is at most 76 elements +//! This is the most important optimization as it means that each row is at most 76 elements //! instead of growing exponentially (76², 76³, ...) //! //! ## Example paths @@ -320,7 +320,7 @@ fn compress(input: &str) -> Graph { break; } - // Follow maze path towards next POI. + // Follow maze path toward next POI. grid[to] = b'#'; to = next; cost += 1; diff --git a/src/year2024/day09.rs b/src/year2024/day09.rs index ed2a093a..59b9345a 100644 --- a/src/year2024/day09.rs +++ b/src/year2024/day09.rs @@ -3,7 +3,7 @@ //! ## Part One //! //! Computes the checksum by simultaneously scanning forward for free blocks and -//! backwards for files. No memory is allocated which makes it very fast. +//! backward for files. No memory is allocated which makes it very fast. //! //! ## Part Two //! diff --git a/src/year2024/day12.rs b/src/year2024/day12.rs index 042d9d87..cd4ded87 100644 --- a/src/year2024/day12.rs +++ b/src/year2024/day12.rs @@ -2,7 +2,7 @@ //! //! Solves both parts simultaneously by flood filling each region. //! -//! For part one we increment the perimeter for each neighbouring plot belonging to a different +//! For part one we increment the perimeter for each neighboring plot belonging to a different //! region or out of bounds. //! //! For part two we count each plot on the edge as either 0, 1 or 2 sides then divide by 2. diff --git a/src/year2024/day16.rs b/src/year2024/day16.rs index c5af42de..c5b28b52 100644 --- a/src/year2024/day16.rs +++ b/src/year2024/day16.rs @@ -5,7 +5,7 @@ //! Part one is a normal [Dijkstra](https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm) //! search from start to end. //! -//! Part two is a BFS *backwards* from the end to the finish, tracing the cost exactly +//! Part two is a BFS *backward* from the end to the finish, tracing the cost exactly //! to find all possible paths. This reuses the cost information from the Dijkstra without //! requiring any extra state keeping for the paths. use crate::util::grid::*; diff --git a/src/year2024/day17.rs b/src/year2024/day17.rs index 739c7a61..46a82eb4 100644 --- a/src/year2024/day17.rs +++ b/src/year2024/day17.rs @@ -17,7 +17,7 @@ //! ``` //! //! This means that the final value of `a` must be zero. Starting with this knowledge we work -//! backwards digit by digit. The right shift wipes out the lowest 3 bits of `a` so there could +//! backward digit by digit. The right shift wipes out the lowest 3 bits of `a` so there could //! be 8 possible previous values. We check each possible value recursively, exploring only //! those that result in the correct program digit. //! diff --git a/src/year2024/day23.rs b/src/year2024/day23.rs index 7fd12132..a0153ead 100644 --- a/src/year2024/day23.rs +++ b/src/year2024/day23.rs @@ -2,7 +2,7 @@ //! //! This is the [Clique problem](https://en.wikipedia.org/wiki/Clique_problem). For part one we //! find triangles (cliques of size 3) for each node by checking if there's an edge between any -//! distinct pair of neighbouring nodes. +//! distinct pair of neighboring nodes. //! //! Part two asks to find the maximum clique, for which we could use the //! [Bron–Kerbosch algorithm](https://en.wikipedia.org/wiki/Bron%E2%80%93Kerbosch_algorithm).