Welcome to another year. First day isn't too complicated, and the only play here is to avoid iterating more than once over a string.
Nothing too hard either, if you know how iterations work. In that case, it's FASTER to only iterate once and store the min and max as you go along, rather than iterating, collecting, and iterating again to gain the min, then iterating once more to gain the max.
As for part 2, it's better to use filter_map() instead of chaining filter then map since our verification is based on doing a (costly) calculation.
Now we are getting somewhere!
Again, half the battle is knowing exactly what to really look for. While part 2 DOES force us to iterate through the field until we get to a result, part one can be solved by understating you are faced with an Ulam Spiral. From there, a little Google can get you prettY eXciting results.
Knowing how to use iterators properly is often the key to winning.
I was expecting more difficulty here.
No idea why, but I cannot get this one to go faster at all.
Little-known fact about me: I hate traversing trees.
That said, you can always find ways to avoid doing it :D
Since we only iterate once with no jumps, no need to save instructions.
The usual: do your best to only iterate every character once. Rust's pattern-matching is really good there.
Funny exercise, the second part was A BIT confusing at first, but it got okay.
Navigating hexagons is a pain. Naive approach is to start with "only change the Y value if we move up, not down", but this will fail you in the long run. What you can do, is treat each hexagon as "two squares": moving up means Y minus 2 and moving down means Y plus 2, while all diagonals work the way they would with a regular grid.
I hate traversing trees. But you don't always have to.
The maths were a bit annoying on this one, and I was hoping for a specific mathematical formula that would prevent me from looping over all scenarios. I found something that felt promising and ported the code from Python, but to no avail, my original code was already faster...
I kinda liked this one.
The most interesting part of these exercises is often all the obscure maths you can learn about, in that case Mersenne prime. But the peculiarities of the number used for the remainder should have been obvious to people who wrote a lot of C.
Nothing hard, until you see how much ONE BILLION ITERATIONS actually is. Good news though: "All loops are about knowing when to stop". In that case, we can just...look for a repetition of the pattern.
As always, there's a trick to avoid looping too much: since 0 is ALWAYS at the 0th position, we just have to store the last number we are inserting (allegedly, no need to allocate a real Vec) after it.
Threading is a bitch.
Worse than maps? Maps that aren't reliably readable by machines.
Nothing too hard here.
That one was both funny and very annoying. Playing with patterns and turning them into fractals wasn't easy.
Very funny exercise, but I'll spend a long time trying to optimize it.
This exercise is actually a trap: running it as expected would last you around ten minutes. Were you to rewrite it as pseudo-code, you would see another algorithm, that is way easier to implement.
Your usual shortest-path algorithm.
Implementing a Turing machine isn't that hard once you get to the principle. Hardest part was actually parsing the input.