Whoo! After yesterday's palate-cleansing interpreter, I'm ready to move on to new things. I'm managing to stay on top of this year's challenge so...
For further actions, you may consider blocking this person and/or reporting abuse
Another good problem for Rust. Because my stated goal is learning the Rust library better I'm doing it all in a text editor without an IDE, which forces you to read the docs rather than rely on autocomplete. I feel I'm writing more code between doc searches now, which is great!
I like your sort of “inchworm” approach to part 2!
It's neat and it passed the tests and got the right answer for me, but I'm not convinced it's totally correct for all input data. I'm sure there are cases it could miss by inching the end forward too far before moving the start.
Because of the contiguous set limitation, it always works. You can't ever go down in value by moving the right end, and you can't ever go up in value by moving the left end.
It's the right approach.
This is the first day I did not OOP it up, because I felt lazy. Part 2 is still nicely linear, but didn't bother to optimise Part 1. Here's Ruby:
Rust solution with more recursion than I do normally.
I had to create 3 variables to store the numbers because of annoying lifetime problems among other things.
Here's my js solution,toggle
part2
totrue
orfalse
depending on your needs :)
Python, should be a reasonably efficient way of doing it although in part 2 it may be better to test the longer sequences first as there are fewer of them.
C# solution.
Top 3 love rank:
`
+1 Rust solution.
I started out with isize because I just knew that the second half would add negative numbers somehow. Then it didn't. :/
I got part 1 done rather quickly comparatively. I then spent far to long arguing with the rust compiler over lifetimes of slices and the ability to sum on borrowed vs. non-borrowed values.
Ultimately I moved into using a more C-style for-loop driven solution, where we walk down the entry vector until we're too big, and then step down to the next item.
Didn't get the elegant interator-driven solution, but meh - a win's a win. :)
As always, on Github.
Today was the first day we got different params for the sample solution, so I had to think about how to make that work with my puzzle runner. I don't love the solution, but it works. Thinking I might do a quick post on the runner, not sure if that would interest anyone...
Overall this was a fun little exercise, not super challenging, though I did have a harder time trying to condense the code for this solution. Not something I typically do day-to-day, but it's a code challenge, not production code 🥳
Anyway, here's my solution for the day
Part1
Part 2
Had some extra time tonight so I got ahead of the curve. The time complexity isn't great, with the loops being a nasty hairy mess, but it works fine :)
This one seemed simple to me. Basic dynamic programming.
More javascript. Still can't see a regex solution. Part 2 contains part 1, so I'll just post that:
Ah, this one lead to a nice relaxing day :-) Nothing fancy in my Haskell implementation, but fine all the same. Relies heavely on lazyness to avoid over production, but if the feature exists why not use it...
My Javascript walkthrough: