How are you doing? Making it OK? Keeping up? I'm starting to bog down a little, but switching to Python when I need to keep caught up has been helping.
The Puzzle
In today’s puzzle, we're planning ahead for our upcoming train trip. We've got a ticket with some numbers, and there are a bunch of fields that these numbers could belong to. We've got to validate our neighbor's tickets to make sure we're on the right track (eh? ehhh?) before we can validate our own.
The Leaderboards
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.
Yesterday’s Languages
Updated 11:18PM 12/15/2020 PST.
Language | Count |
---|---|
Rust | 2 |
Haskell | 2 |
Python | 1 |
JavaScript | 1 |
Ruby | 1 |
COBOL | 1 |
Merry Coding!
Top comments (8)
Here's my Haskell solution. It was farily easy today, compared to some of the others, and I took my time between part 1 and part 2, to walk the dog in what turned out to be a very wet and muddy time.
Part 1 JS solution, I've been hearing that Part 2 day 16 is a very hard part
😳, hope I'll be able to finish that
Today was a LOT of fun! I finished it quickly, but only was able to work on it just now. It's not a nice solution (unlike many other days where I took the time to OOP it up), but it works very well (sub 20ms) and I think isn't too bad to read.
Ruby:
Probably the hardest one so far this year. I was caught out in part 2 by using part 1''s solution - I was using an "error count" > 0 to find invalid tickets, but there's one record where the only invalid field has value zero, so the "error count" is zero. Fixed by changing it to the arguably clearer and definitely more efficient check that no fields are invalid.
My rust impl. Pretty gross use of "exactly one match" boolean thrashing. But, I was in a hurry and didn't want to mess with it any longer :)
Today's Haskell solution, much longer than yesterday. The parsing was a bit annoying today, but not too bad. Part 1 was very easy. Part 2 was extremely tedious, but at least no performance issues today. I'm still pretty satisfied with my solution and it worked on the first try.
Whew! I think in any other language, this would have been a lot smaller and less verbose, but C made me work it all out loop by loop. It's so much code. My eyes are crossed.
But it works great! I got foiled right at the end by a "not big enough output type" bug that had my answer overflowing and becoming too small. And did a butt ton of debugging and going in the wrong direction before slapping my head and hitting a bunch of undos.
Anyways, I'm pretty happy about how it finally turned out. There were a lot of moving pieces and I think I handled them, if not algorithmically quickly, at least cleanly and readably. And it's still pretty fast.
Also, I love
strtok
. That is all.My JavaScript walkthrough: