Getting the count of each card, the two highest counts easily show what type of hand we have. For part 2 I just added the number of jokers to the highest count.
I spent some time messing around with generics to minimize code duplication between the solutions to both parts. I could have absolutely just copied everything and made small changes, but now my solution is generic over puzzle parts.
Oh yeah, that's clever. I'll remember that when it comes up again.
I went with solving the quadratic equation, so part 2 was just a trivial change in parsing. It was a bit janky to find the integer that is strictly larger than a floating point number, but it all worked out.
Ooof. Part 1 was easy enough, but for part two I initially went with the naive solution of trying every single seed which took more than a minute (I never really measured). Although that got me the right answer, to me that was just unacceptable.
I proceeded to try and combine all mappings into one but gave up after spending way too much time on it.
Then I had the idea that the lowest number in the end must lie at the beginning of a range somewhere. Either the start of a seed range in the beginning or the start of a range in one of the mappings. Any in-between numbers must end up with a higher result. So I considered the start points of all ranges, went through the mappings in reverse to find out if that point is actually within a seed range, and only tested those starting points.
Finally I had only 183 points to test which ran much faster (0.9ms).
You were so right.
You're trying to iterate over a Vec while mutating its contents in other places, which is something the borrow checker doesn't like. Altough the later cards that get their copies count increased aren't the same as the iterating reference card, Rust forbids two mutable references into the same Vec, even if they reference different elements of the Vec.
You could try to iterate over indices into the array instead of directly over array elements, then you get rid of the reference in the outer loop. This would probably require the least change to your code.
Another option would be to split apart the data structures between what needs to be mutated and what doesn't. I've solved this puzzle in Rust and had a separate mutable Vec for the number of copies of each card. Then you can iterate over and mutate both Vecs separately without having conflicting references.
I have a sway workspace indicator on the left, the right side has:
I have also switched to Colemak and my advice is to just not do that. Just learn Colemak without looking at the keyboard, it'll make you a better typist anyway and you can get comfortable with it within a few weeks. In particular you don't want to move the little knobs on the index finger keys (F and J).
The hexagon minecraft one is neat.
This one wasn't too bad. The example for part 2 even tells you how to process everything by visiting each card once in order. Another option could be to recursively look at all won copies, but that's probably much less efficient.
Indeed, my solution fails on this input (returns 10, which is the location to seed 0), but it can be easily solved by also adding the ends of each range as well.
Maybe the input was quite forgiving. Thinking about it more, reversing the mapping can get quite involved, because it is neither surjective nor injective, so the inverse can actually have any number of results.
In your example there is no input that maps to 0, but there are two inputs that map to 11 (1 and 11). If the seed-to-soil map also included
10 20 2, 21 would also map to 11.