I did the same thing as well, the inputs are fairly simple to parse directly

that's totally valid and I'll never tell you not to do that if that's how you want to do it. AoC, as you said, always produces valid input so an error in parsing is always an error in the player's program. Using a parsing library for a parsing task is not something I consider overkill though.

That's a pretty good challenge, especially if you're familiar with Advent type problems and Rust already.

any number of reasons really. Probably mostly that the windows pc has a newer cpu. (m1 vs ryzen 7950x)

The site makes a note about making sure you're not making too many requests to the servers, but doesn't define how many is too many, so I generally avoid putting any more load on their system than I have to.

Should be easy to implement some sort of caching though, right?

honestly, committing it to the git repo is already the best form of caching to use in this scenario. Anything else is a workaround.

> it looks like some of the digits are actually spelled out with letters > aoc day 1, part 2 A valid interpretation of this is that digits are being replaced by words, especially since part 1 included no overlapping. 7 and 7 is not an overlap, it is the same number, and the problem description does not say "search from the left and the right and find the first number you can from either direction". The overlap in the second test case is inconsequential and can be completely ignored/missed because it is inconsequential and has no effect on the answer. The player is left to wonder if the overlap should read one way or another *because* it was underspecified and inconsequential in the test input. > the first digit and the last digit The "last digit" changes based on how you interpret the input, which is not well-specified in the test input or the problem description.

@@chrisbiscardi I doubt that we will agree on this. But consider twoneight: left-to-right string replacement would have first- and last-digit be 2,8. Right-to-left replacement would give the same answer. But ascending-numerical-order replacement would give 1,1. i.e. string-replacement is not a well-defined method without further information. String-search without-replacement is well-defined: it gives the correct 2,8 here, and 7,9 for sevenine, regardless of the direction you process or the order you search. I would never have imagined the "replacement"-based reading at all, but given the choice between an interpretation that gives a well-defined solution and an interpretation that cannot be meaningful, I'll take the well-defined one any day.

@@pineberryfox yeah, you're so close here though. "given the choice of interpretations" is what you're saying here, but there shouldn't have been a choice. The puzzle should tell you the rules of the game and it didn't. You chose correctly, which is great, but there is nothing about the puzzle which indicates the correct interpretation until you run the solution on the real input. The puzzle could have said "the string numbers read the same right-to-left and left-to-right", but it didn't. The puzzle could've given an example of "twoneight" being 218, but it didn't. That's a choice in interpretation that you made based on incomplete information. 70,000+ people hit this issue and dropped off permanently. There is something wrong *with the puzzle* when almost a third of players are dropping off on day 1.

@@chrisbiscardi The puzzle could not have given an example of twoneight being 218, because it isn't, it's 28. Explaining that it contains instances of "two", "one", and "eight" where "two" is first and "eight" is last might be fine, but then you're giving people a lot of extra, unnecessary information. I'll concede that the phrase might be ambiguous. But then, if you have two ways to interpret something, and one way leads to more unaddressed ambiguity while the other clears it up immediately, the unambiguous way is the way. Don't get me wrong, i'm not saying the puzzle would be made worse by including an example like "eightwo", i just feel like the couple people i've seen rag on its lack are being overly critical. Maybe Eric disagrees with me, agrees with you, that's fine too. On people leaving: i'd expect the curve to be roughly Zipfian, so I'm not sure how much the puzzle whose solution is to scan a string one-position-at-a-time is contributing to people leaving. If it scared people off: that sucks.

@@pineberryfox yeah, my critique is not meant to be "puzzle bad" but rather "55k *more* people dropped off this year on day 1 than last year, even though the total participation was pretty constant at 300k-ish, and I think this is why"

absolutely impossible to say why you got a clippy warning without seeing any code or even the warning id that you got. It does not get flagged the way I show in the video.

@@chrisbiscardi My bad. The lint is called filter_map_bool_then and only applies to bool::then. The clippy lints page cites not working on then_some as a limitation.

@@adrianjdelgado thanks for mentioning the name of the lint. I went through and made a bunch of changes to see what this would look like. While it is ok in some cases, in others it results in bending over backwards to satisfy the lint. Its also notable that the original issue that caused this lint to be created wasn't motivated by the use of then_some, it was motivated by the use of a dozen-line complex computation inside of a then(). None of my usages of then_some satisfy that condition (they are all simple "use this value"s), which the lint as-implemented also doesn't check for. In the end I decided not to apply the changes. Clippy style lints are particularly opinion-based, which is why they're in clippy and under the "style" group in the first place, so while I might follow it in the future, I don't think the change is worth it right now. github.com/ChristopherBiscardi/advent-of-code/pull/20/files

@@chrisbiscardi Fair enough :)