I'm using AoC this year to learn Rust, so I really appreciate the time you've put into doing this.

I'm already stuck on this though with array_windows, particularly these lines

.array_windows()
.filter(|[a, _, _, d]| a < d)

I'm very confused on how this works. My understanding is that array_windows creates a moving window iterable, and so I'm stumped on the following:

• how is it inferred that the window is 3 elements in length?
• where is the sum performed?
• how is array_windows different from windows?

I appreciate any help you can offer

Hey there Tim,

First of all, thank you very much for working on this year's advent of code in the open in Rust, it's really helping me learn.

I'm having quite a hard time grasping the intuition behind the bit-shifting going on in the first part of the day 3 solution. I understand that at a high level, a left bit shift multiplies by two and a right bit shift divides by two. What I don't understand is for example on line 12 where bits is ANDed with 1, shifted to the left i, then immediately shifted to the right by i, and finally added to the count.

Line 17 is also hard for me to understand and would love some explanation there as well.

Perhaps if you (or anybody else for that matter) has a spare moment and could help me understand what is going on that would be awesome!

I appreciate your work very much!

Hello! I'm reading your solution to day 6, and I can't figure out why did you add 7 when iterating through the days for the index. If you can explain that to me I'd be greatly appreciated!

Hi there, I'm reading the solution of day 9 part A and I do not understand this line

                sum += (cell - b'0') as usize + 1;

What is b'0'?

I'm pretty new to Rust, and in this case I'm not finding anything in documentation. ...or I don't know where to look 😭

Thanks a lot!

The current code runs into the unreachable code macro.

I'm not sure why, but I think the &[u8] array was not split at this.split(|&b| b == b' ') command.

Hello, thanks for putting these solutions!

I wish to ask where hyperfine is used in the codebase, as it is mentioned in the README. It seems to me that the runner rust programs are using the took crate instead.

Hey Tim it's me again 👋

If you have a moment, would love some explanation behind your day 6 optimized solution, purely out of curiosity. How did you come up with it? Thanks!

Absolutely no worries at all if you do not have time/desire to answer! But thought I'd ask just in case you do.

Thanks for your work!

One suggestion for day17a is to directly calculate the answer instead of "firing" a shot. The probe will hit the x-axis with a velocity of -by (start velocity). So in the next step it should not overshoot, therefore n(n+1)/2 = -(min(by))-1

fn main() {
    let input = "target area: x=269..292, y=-68..-44";
    let bounds: (i32, i32) = input[13..]
        .split_once(", ")
        .and_then(|(_,by)| {
            let (y, yy) = by.split_once("..").unwrap();
            Some((y[2..].parse::<i32>().unwrap(), yy.parse::<i32>().unwrap()))
        })
        .unwrap();
    // Solve n(n+1)/2 where n = -(min(by)) - 1
    let n = -bounds.0.min(bounds.1) - 1;
    println!("{}", (n*(n+1))/2);
}

For the input

1,1,1,1,1,1,20

the current code returns 172, while the correct minimal fuel consumption is 171. After doing a few estimates with paper and pencil, I believe it's enough to check the ceiled and floored arithmetic mean, but simply rounding to the nearest integer is not enough.

Note that the current code also fails on real-world Advent of Code inputs, notably on mine. :)

A solution I believe to be correct is here: https://github.com/smarnach/aoc2021/blob/master/src/bin/day07.rs

The pathfinding library implements classic dijkstra's algorithm by a BinaryHeap.

It can be further improved, some of my thoughts are:

1. We can use a bucket queue because all weights are small integer, so the cost must be an integer between (0, 9 * V), where V is the number of vertex.
2. We can pre-compute a tighter cost upper bound than 9 * V thanks to the graph setup. Generally we don't know the path from start to end without traversing. However in the aoc setup, we do know a path from start to end: so we can sum up the risk from (0, 0) -- (W - 1, 0) -- (W - 1, H - 1) and use that as the bucket size.

I implemented the bucket queue dijkstra and it's around 20% faster than the binary heap approach on day15b setup.