AdventOfCode2021
My solutions to the AdventOfCode 2021 in Rš (by JohannesFriedrich)
aoc2021
My solutions to Advent of Code 2021. (by ritobanrc)
AdventOfCode2021 | aoc2021 | |
---|---|---|
2 | 13 | |
4 | 0 | |
- | - | |
3.2 | 0.0 | |
over 2 years ago | almost 2 years ago | |
Rust | ||
- | MIT License |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
AdventOfCode2021
Posts with mentions or reviews of AdventOfCode2021.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-12-03.
- -š- 2021 Day 4 Solutions -š-
-
-š- 2021 Day 2 Solutions -š-
Day2 solution in R https://github.com/JohannesFriedrich/AdventOfCode2021/blob/master/Day2/Day2.Rmd
aoc2021
Posts with mentions or reviews of aoc2021.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2021-12-10.
-
I learned a bit about Path Finding Algos today
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
-
-š- 2021 Day 11 Solutions -š-
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).
-
-š- 2021 Day 10 Solutions -š-
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.
-
-š- 2021 Day 8 Solutions -š-
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.
-
-š- 2021 Day 7 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.
-
-š- 2021 Day 6 Solutions -š-
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.
-
Advent of Code rust nuggets
From u/ritobanrc (full solution): use nalgebra::Matrix5 and you can use column_iter() and row_iterator() on your board.
-
-š- 2021 Day 4 Solutions -š-
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.
-
-š- 2021 Day 2 Solutions -š-
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.
-
-š- 2021 Day 1 Solutions -š-
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).