Advent-of-code VS aoc2021

Wow, almost identical to mine: https://github.com/MichalMarsalek/Advent-of-code/blob/master/2022/Nim/day6.nim

This year I was writing two sets of solutions in Nim. The first one focuses on idiomatic, nice and short and readable Nim. The other focuses purely on speed. The combined running times of the fast solutions is 130 ms. Please let me know if you have any tips on how to make my solutions more simple and/or idiomatic.

Beautiful Nim! My solution is actually very similar.

Can confirm, I implemented Djkstra badly (I made it visit every single cell, instead of stopping once it reached the end, since that's what wikipedia did), switched to A* w/o visiting every single cell, got the answer for part 2, and returned to the non-stupid Djkstra and measured -- A* with manhattan distance is about 5ms faster than A* with euclidean distance (since it avoids the square root, and the euclidean distance is actually less appropriate in this situation), and Djkstra beats the Manhattan distance by another 5ms. You can look through all my implementations in the commit history for this file: https://github.com/ritobanrc/aoc2021/blob/main/src/day15.rs

Rust, not my proudest code, honestly quite messy, I couldn't decide whether to represent points as Vector2 or usizes into a vector, using both a HashSet for flashed but a Vec for to_flash feels silly, especially since it calls contains on both in the same condition, nor am I proud of the rightward drift resulting in five layers of braces, and the messy conditions on neighbor. But nonetheless, it works, and part 2 was easy enough to hack in on top of part 1, with a couple extra lines (albeit, still a bit messy, with a range 0..usize::MAX since bounded and unbounded ranges are different types, and an unreachable!() in the match statement at the end).

Rust. I found today surprisingly easy, much better than the last couple -- part 1 was quite simple, just keep a list of the open ones and close them as necessary. Part 2 should have been trivial to implement on top of that, but I wasn't correctly discarding the corrupted lines, and apparently sorting a list and finding the median without off-by-one errors is hard, so that took a while to debug.

Rust -- part 1 was fairly easy, but I had absolutely no clue how to do part 2 for a long time. I ended up just brute forcing it, trying every single possible wire re-arrangement (thanks itertools::permutations). I used a bitmask to represent which lights were on (no idea if its necessary), but it was a fun exercise trying to get the bit fiddling right -- I was pleasantly surprised when it just worked (ig that's the benefit of writing small, fairly self-contained routines). My initial answer for part 2 was also reversed (3535 instead of 5353), which is why there's a rev in there near the end. Overall, very fun challenge -- I enjoyed not knowing how to approach it initially, and I'm sure lots of people will have far more clever solutions.

Rust, basic bruteforce solution. Played around with trying to find an analytic solution for a couple mins, but ended up just brute forcing it, and surprisingly, its not absurdly slow.

Rust. Unsurprisingly, I did the naive thing for part 1 and then had to re-write for part 2. I'm happy with how clean part 2 is, I just used a Rust array for the counts -- though I'm sure there's a more clean solution for shifting an iterator.

From u/ritobanrc (full solution): use nalgebra::Matrix5 and you can use column_iter() and row_iterator() on your board.

Rust -- Happy with how my code turned out for today. I used nalgebra's Matrix5 for storing the boards, which made checking for wins pretty easy.

Rust, nothing special here, not particularly fast (I initially thought aim should be a vector and lost some time because of it). The error handling could be a bit cleaner, I might fiddle with that for a bit so I don't have to put .unwraps and .expect and panic! everywhere.

Here's my solution without any collects: https://github.com/ritobanrc/aoc2021/blob/main/src/day01.rs -- but I don't think you could do it without itertools, since windows is only implemented for slices, and array_windows for iterators is still unstable (pending const-generics).