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 far, and I think it's the longest I've managed it so consistently. But we'll see how things go. We're not even halfway yet.
In today’s puzzle, we're tasked with finding a weakness in the XMAS data cypher system (which consists of streams of numbers with requirements about sums) by finding the number that doesn't fit the pattern. As long as it doesn't have a big complicated string to parse, I'm happy.
As always, this is the spot where I’ll plug any leaderboard codes shared from the community.
Ryan's Leaderboard: 224198-25048a19
If you want to generate your own leaderboard and signal boost it a little bit, send it to me either in a DEV message or in a comment on one of these posts and I'll add it to the list above.
Updated 03:09PM 12/12/2020 PST.
Top comments (17)
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.
Here's my js solution,toggle
falsedepending 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.
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
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.
This one seemed simple to me. Basic dynamic programming.
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 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:
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...