Advent of Code 2024 Day 2 - Full Solution

[@marklord7614]

II can't emphasize enough how valuable these sessions are. There's definitely benefit in watching your code and projects, but tackling the same challenges together is even better. Firstly, viewers can get familiar with the code on their own before tackling the problem independently. Then comes the real value: comparing how you reason through the problems and translate them into your coding style. I learn a lot more this way and I'm interested in hearing other opinions.

[@rakeshkumarreddymudda]

Hi zoran I like all of your vedios. Just a small suggestion if you can elaborate question before getting in to solution might be more helpful. Again it is just a suggestion your vedios are always good as 💎

[@kalvikaring1304]

Whoever fixes the floating numbers in CS will also fix the floating numbers in JS. BTW you write nice and clean code and I love it!

[@zoran-horvat]

float and double are defined by the IEEE standard and, as such, they are built into every CPU. There is nothing a programming language can do to change it.

[@kalvikaring1304]

@@zoran-horvat Thanks for joggling my memory

[@billy65bob]

I vaguely recall reading something about an alternative floating point implementation that was underway some 15 years ago. I think they were called "positrons", and offered more precision, 2's complement (so no more -0), and much fewer ways to get NaN.

[@abj136]

@@billy65bob given the importances of vast libraries and techniques in the world today “somewhat better” is not sufficient to replace existing floating point. Eg., look up BLAS and what lies beneath it.

[@Tesfamichael.G]

Thank you Zoran!

[@asrajan55]

Just beautiful!

[@Deathflame82]

Hi Zoran, FYI the Pairs method can also be done with values.Zip(values.Skip(1))

[@zoran-horvat]

@@Deathflame82 Yes, that is the technique I used in one of the other days. However, if you plan to extend LINQ, as you probably would on a real project, defining a more optimized operator pays off. Not to mention that the Zip technique is not safe on IEnumerable, only on concrete collections.

[@weakener]

​@@zoran-horvat Hi, can you elaborate on this? What are the potential problems with using Zip on IEnumerable? Thanks!

[@zoran-horvat]

@weakener IEnumerable doesn't guarantee you can iterate it twice. Take this video as an example: I could have created an IEnumerable by lazy-evaluating the console input. Using Zip would cause getting more strings from the console and converting them to a completely different sequence!

[@rastislavsvoboda4363]

public static IEnumerable ExceptAt(this IEnumerable source, int index) => source.Where((_, i) => i != index);

[@zoran-horvat]

@@rastislavsvoboda4363 When the argument is a list, Take and Skip are faster, because the list knows how to procure those elements directly.

[@harisimer]

​@@zoran-horvat in other words, to get an element via index you dont need to check the index. Which the .Where method actually does. But I dont know how the .Concat optimizes into this, it should cause every element to be copied twice right?

[@zoran-horvat]

@harisimer Not copied twice, but once. Nevertheless, LINQ uses specialized collections internally, which tend to hold items in an array or a reference to an array when possible, sometimes leading to tremendous improvements in speed. That's why I choose to make straightforward calls, hoping for some optimization. Someone once said: even if there is no optimization today, there will be one tomorrow and your code will suddenly start working faster.