Day 02 - Advent of Code 2023

[@flwi]

This series is excellent learning material for my rust journey! Happy that I found your channel!

[@kijetesantakalu]

So interesting to see how different everyone's approach is, even with simpler puzzles like the ones today.

[@omarmagdy1075]

Man your advent of code content is such a high quality content and almost every time I learn something new about rust std library yesterday it was inspect() and today was then_some(). Just love these keep em coming please

[@chrisbiscardi]

glad you're enjoying them! I'll be here with advent videos all month. There's a playlist here -- kzbin.info/aero/PLWtPciJ1UMuD3_8Pb-EqrFhkYpastR2cn

[@topi3146]

I aggree. It is really interesting as rust learn to solve these puzzles for yourself first and then come here to learn how to do it using the std library.

[@Beedsta]

Enjoying AoC so far, especially coming to videos like this and comparing my solution, and learning new tools/approaches!

[@lilium724]

Really love you videos, thanks for keeping me motivated to learn more Rust! 26:43 one other alternative would have been to use the nom::combinator::iterator you can use it to iterate over the parsed input as it's being parsed, so there's no need to bake the logic in the parser or to allocate any memory

[@chrisbiscardi]

Glad you're enjoying the videos! I did a short take on an iterate approach and for part 2 it dropped from 90k to 22k heap. Still a bit messy, but it looks like this right now: github.com/ChristopherBiscardi/advent-of-code/blob/c8ccc5cb0f90d31565070be2187f9b499cfedca4/2023/rust/day-02/src/part2_nom_iterator.rs I don't quite follow how we'd avoid baking the logic into the parser or allocating any memory (perhaps if we avoided Map and hardcoded to 3 colors), but I might still work on it a bit more later.

[@bulkan.evcimen]

I just solved this using string splitting and came here to watch how you do it a more rust like way. The second you said "write a parser" stopped a video and found your "Write better parsers with Nom Supreme" video 🎉

[@de_grote4758]

Thanks for making a day 1 with nom! It's really useful for me considering I spend almost an hour on parsing and just gave up on parsing on part 2

[@natescode]

Hand writing a simple parser is a great exercise.

[@yondaime500]

I still haven't brought myself to learn nom, because just using the regular Rust methods always seem easy enough whenever I have to parse something.

[@chrisbiscardi]

You can totally get through advent of code by using stdlib methods like split. I mostly use nom because I trend towards using crates that I'd use to solve similar issues in regular work throughout the year. Very much "an opportunity to practice" rather than "necessary for advent of code"

[@BlackSharkfr]

I also had trouble the first time I tried using Nom. As soon as I started attempting to use preceded, terminated, separated pairs... I quickly got lost in the functions within a function syntax. Things got much better once I understood you can use nom using flat syntax rather than functional syntax. For example a functionnal separated pair : let (input, (a, b)) = separated_pair(digit1, tag(" "), alpha1)(input)? can be written linearly : let (input, a) = digit1(input)?; let (input, _) = tag(" ")(input)?; let (input, b) = alpha1(input)?;

[@chrisbiscardi]

@@BlackSharkfr yes, 100%. This is why I show it using the (input, _) syntax to start with. Its totally possible for me at this point to write long chains of nom parser, but as I mentioned in the video, splitting it out into different functions and writing with the priority for the code to be *read* later is something I think is more important than writing small concise chains.

[@제인-y9u]

Was looking forward to this.

[@JohnnyVestergaard73]

This is funny... my solution values were the exact same numbers... so much for unique input 🙂

[@chrisbiscardi]

it happens. sometimes there are days when *everyone* has the same test input and other days everyone's are different. The puzzles are hand-written as far as I know, with a bit of help generating the inputs.

[@OmegaLok]

Really enjoyed the first day as I am learning rust. I'd prefer to see more of the basics to wrap my head around idioms etc... and this day felt like too much boilerplate for a problem which was ultimately quite basic

[@chrisbiscardi]

all of the advent of code problems are ultimately "quite basic" in the way you're using the phrase here. They're puzzles meant to be solved in a short time frame, not production software. My approach is going to lean more towards how I would write software for real projects, but writing as little code as possible is totally valid if that's how you want to approach it. The whole approach today can be boiled down into three functions. one parser, one for the logic, and one to call them. I write the long way in videos because its easier for someone who is new to take the code and start modifying it without running into type errors they have a hard time debugging. Here's the more concise approach: play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0f44c9fa22f3cb78b6c47c5de2802615 What basics are you looking to see more of?

[@saiprashanth1941]

Still cant wrap my head around this kind of coding stuff😢 but i really want to master this kind of problem solving skills😢

[@chrisbiscardi]

If you ask questions about what's confusing I can dig into it more

[@saiprashanth1941]

@@chrisbiscardi thank you chris would love to know how to analyze and get on working through a problem like this? Are there any prerequisites to solving coding problems?

[@saiprashanth1941]

@@chrisbiscardi im a front end developer but i just started to learn rust cause im interested in doing backend but i really do struggle when it comes to logical question or data structures

[@chrisbiscardi]

> thank you chris would love to know how to analyze and get on working through a problem like this? Are there any prerequisites to solving coding problems? For advent of code its pretty formulaic for me. The input needs to be either parsed or generally processed into a form that I can use in the problem. Sometimes this is simply taking each character one by one and other times its building up objects (structs are just typed objects). Then you need to do something with that data. Depending on what you need to do you'll figure out how you're going to need to access it. And your access patterns determine what the best data structure to use is. In advent of code this is often a regular Vec or HashMap, but later problems can also make good use of graph structures. Sometimes more exotic data structures help but those are usually optimizations. > im a front end developer but i just started to learn rust cause im interested in doing backend but i really do struggle when it comes to logical question or data structures Overall I'd suggest getting familiar with Vec and HashMap first. Go to the docs pages for those types and read the available functions. This will give you some context for how you can use them. I wouldn't necessarily say there are pre-requisites to solving advent of code problems, but if you haven't done it before it will definitely take longer than if you've done a lot of them

[@saiprashanth1941]

@@chrisbiscardi thank you for the suggestion im just going to keep on trying and keep up the great vids Chris love those vids

[@kevincodes674]

Nice. I messed up Part 1 with Enums... came to a similar solution in the end but made just a Round struct with colors as keys. Part 2 was much easier lol

[@iglobrothers645]

I just did it the brain dead way and split the input line first by the colon then the the semicolon and then the comma... And then parsed all the numbers to u32

[@markday3145]

I id it that way, too. A Game is struct with ID plus a Vec of Rounds, and a Round is a struct with 3 u32's (for red, green, and blue). I had to handle a little more during parsing (for example, matching against the possible color names; and missing colors in a round). But then the calculations for parts 1 and 2 were pretty simple.

[@yumbuboyumbubo8230]

Same here. Yeyy split gang! 😊

[@Gers217]

I wonder if you record and edit these videos right after completing the puzzle

[@chrisbiscardi]

I record them as I'm doing it

[@ragectl]

The funny typo of your Cube where you had 'Greed' instead of 'Green'

[@Iuigi_t]

Some puzzles are just easier in C and C++ with pointers for easier parsing

[@HirschyKiss]

This is too complicated for me still, haha. I just used a regex match to pull out the game_id ( `r"Game (\d+)"`) and color amounts `format!(r"(\d+) {}", color)` and saved the colors to a vec where I could run .max() or check to see if .any(number> color_totals) Which I'm sure is much slower, but oh well. I'm still get 30ms run times. Hopefully by the end of AOC I'm comfortable building out structs and enums and shiz

[@chrisbiscardi]

yeah totally! Don't worry about it too much if you're just getting used to the idea of structs and whatnot. My goal here is to make you aware of it, not tell you you have to do it this way now. 30ms is way fast enough for advent of code.

[@hamster8371]

any chance you could increase your bitrate for the next videos? scrolling text looks awful.

[@chrisbiscardi]

yeah I'll revisit the settings. I think they dropped when I was doing some updates.

[@TheNardow]

Interestingly, the result values changed since then.

[@chrisbiscardi]

Inputs are mostly different across players. My answers will not be your answers, which is why I don't hide my answers when filming

[@MrTact67]

There's something in the solution to part 1 here that I think is fundamentally flawed. One of the great strengths of Rust's algebraic type system is that you can build your data structures in such a way that invalid states are unrepresentable. That isn't the case here. Specifically, by defining the rounds member of the Game struct as Vec, you have made it possible to have more than one entry with the same color in a round. Obviously, this is a trivial example and the input is clean (i.e. you can see all of your input data, you can be confident it doesn't exhibit this error, and it parses cleanly using a very simple parser). But on a fundamental level, what you're doing with this approach is to shift the burden of safety from the compiler to the programmer, which I would call a Rust antipattern -- IMHO doing the opposite is kind of Rust's central value proposition. Especially given that the enum-based approach that you started to write wouldn't have been that much more work, and would eliminate the potential for this error to even occur. Having offered that critique, let me say though that I do really enjoy and appreciate this series. I especially liked that you whipped up a nom approach to this problem. I thought about doing that, but it's been long enough that I had to monkey with nom, I didn't want to have to essentially relearn it. Seeing how easy it is here, I probably should have just bit that bullet!

[@chrisbiscardi]

absolutely. The reason I kept it as a Vec is because I wanted to be open the the potential that the real input would change the number of colors, so I decided to avoid depending on the fact that the colors in the test input were statically knowable. That said, the Vec could have been a BTreeMap and it would address the concern as well, which I think is a change I'll go back and make now. It didn't cross my mind to do so at the time I was recording (such is the downside of recording as I solve!) Glad you're enjoying the videos!

[@SuperScrapland]

Why do you use so weird libraries to solve the problems? :D

[@chrisbiscardi]

What do you think is weird about them?

[@luna0609]

I really like your explanation 🤩! And I hope you do the same for remaining 23 days 😅

[@narigoncs]

First :)

[@narigoncs]

Love everything you do, keep it up!

[@Gers217]

Lucky