Gobbel2000

Rust

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.

Rust

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.

WTF

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:

• Monitor brightness
• Volume
• Local IP address
• CPU temperature
• Keyboard layout
• Local date and time
• UTC time
• Tray

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.

Rust

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.

What do you know? How do you know!?

I like it, it's simple and to the point. I've learned that one of the most helpful things to do when solving these puzzles is to not make it more complicated than it needs to be, and you certainly succeeded better at that today than I did.

Rust

I've been using Regexes for every day so far, this time it helped in finding numbers along with their start and end position in a line. For the second part I mostly went with the approach of part 1 which was to look at all numbers and then figure out if it has a part symbol around it. Only in part 2 I saved all numbers next to a gear * in a hash table that maps each gear position to a list of adjacent numbers. Then in the end I can just look at all gears with exactly 2 numbers attached.

Also it has to be said, multiplying two numbers is the exact opposite of getting their ratio!