Seems to me that people made part 2 harder than it us. Just define an array containing the digits: "one", "two", and so forth. Then check for substring matches, position by position. Maybe not elegant, but effective.
I think the issue is that they tried to separate the input into a list of tokens, like ["5", "nine"], and work from there, which doesn't work on something like "oneight".
Advent of Code 2023 is nigh
241–250 of 319 posts
Re: Advent of Code 2023 is nigh
#242Earlier quoted context omitted.
I don't get the amount of effort people out into the replacement-strategy, I did perfectly fine without it and the code is about as complex as the examples I've seen. https://github.com/codr7/swift-interpreter/blob/main/part10/...
Yeah, all the talk of replacement seems like people masively overthinking or abstracting a day one problem. My C++ solution was a simple search using the header. It's a little less neatly abstracted out as yours, and could be cleaned up a fair bit, as I wasn't bothered to deduplicate the code after getting it working (and I will if this turns out to be useful tomorrow), but the essence is the same: https://gist.githu…
My solution in Kotlin https://github.com/kolonialno/adventofcode/commit/686cbebb07...
Re: Advent of Code 2023 is nigh
#243Part two was exceptionally hard. Many people on reddit reporting they were hit by one edge case that's not covered in the examples. But my implementation passed these edge cases too. I was hit by another edge case. So there are at least two edge-cases (which are in the actual data) that aren't covered in the examples or the description.
It was a little frustrating that the main edge case that caught everyone didn't blow up my implementation, and going row by row of the 1000 line input it wasn't immediately obvious where it was going wrong (I'm not sure how far down I would've had to go to find the first time it hits this edge case, I just ended up checking the reddit for hints). I really do think things like this should at least be hinted in the tex…
Once I diffed it against a working output it was clear and solved within minutes.
Re: Advent of Code 2023 is nigh
#244Earlier quoted context omitted.
Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril. These edge cases are triggered by fundamentally approaching the problem incorrectly. In some ways it's excellent to bring that up early in a way that's relatively easy to debug and diagnose. Like many others I started with the wrong solution, and I was hit by the same problematic cases, but what I found interesting was…
Further spoiler: I replaced "one" with "o1e", "two" with "t2o", etc. which is hacky as hell, but works for throwaway contest code. (Replacing as suggested above also works, but is more typing.) That let me keep the problem in the filter/map/first-last/reduce space, which was the shape of my solution to part 1.
Re: Advent of Code 2023 is nigh
#245Earlier quoted context omitted.
Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril. These edge cases are triggered by fundamentally approaching the problem incorrectly. In some ways it's excellent to bring that up early in a way that's relatively easy to debug and diagnose. Like many others I started with the wrong solution, and I was hit by the same problematic cases, but what I found interesting was…
> These edge cases are triggered by fundamentally approaching the problem incorrectly. That's a bit like you are holding the phone wrong kind of statement. These are just coding exercises, not actual business problems.
There's never been a customer that asked me "I have some elves that need to make snow and here's a trebuchet", sure. But they ask me stuff, I intepret that as well as I can. Go back for questions. Apply DDD, event-storming or whatever if I'm lucky.
But there always is an interpretation issue somewhere, that makes that some "bug" is really "but I spend 5 hours implementing that exception and now you tell me it's a bug?".
Re: Advent of Code 2023 is nigh
#246Earlier quoted context omitted.
I used BurntSushi's excelent aho-corasick, which unsurprisingly implements the Aho–Corasick algorithm (overkill I know). It did take me a while to realize though that there are overlaps which meant that my code worked on the example input but not on the real input (fortunately the library has you covered in both cases). I have the code on my GitHub but solve it yourself first, it's fun. https://en.wikipedia.org/wiki/…
I first brute-forced the solve (on each line, find and rfind every digit, keep the smallest find and the largest rfind), that worked fine out of the box as that's not sensible to overlap. I then figured I'd use aho-corasick because that was an opportunity to, and there's no kill like overkill. I then proceeded to waste half an hour because I didn't read the documentation, so I didn't see that `find_iter` finds non-ov…
In particular, the SIMD optimizations in the aho-corasick crate only apply when MatchKind::LeftmostFirst or MatchKind::LeftmostLongest are used.
[1]: https://docs.rs/aho-corasick/latest/aho_corasick/enum.MatchK...
Re: Advent of Code 2023 is nigh
#247Earlier quoted context omitted.
You might try BurntSushi's aho-corasick crate. It led to a fairly nice solution in Rust for this one. (It will report overlapping matches)
I would assume you can also use RegexSet from the regex crate, as it > match(es) multiple, possibly overlapping, regexes in a single search.
With the Aho-Corasick implementation you can just map the string -> {ordered list of matches} -> numbers associated with the match, and then you've got a little vec of digits you can grab the first and last entries of. Ended up being just a few lines of code, together with a hard-coded list of ["0", "one", "1", "two", ...] and the numbers they mapped to [0, 1, 1, 2, 2, ...].
Re: Advent of Code 2023 is nigh
#248It's a tough day 1, I hope it doesn't scare off too many people. Normally day 1 is just some variation of "add numbers in a list", but this year has a mean pt 2 and a few traps for people to fall into. I wonder how long the global leaderboard will stay up before it gets hidden due to people solving with ChatGPT?
I'd actually welcome it if the leaderboard was abolished. I never really played for placement, but something about the fact that the board was full of people who routinely solve every problem in about the same time it takes me to even READ the description was a bit demotivating. I always felt this racing aspect to be somewhat at odds with the idea that this is a challenge that you can complete in your own time, maybe…
Re: Advent of Code 2023 is nigh
#249Earlier quoted context omitted.
Generally, such edge-cases usually make the solution ugly and the process unpleasant. The aim of such puzzles should be a pleasant process culminating with a beautiful solution.
The potential for overlapping numbers was the thing that tripped up many developers. But a simple “find the first number searching from each end, just like the puzzle instructions asked” implementation just worked. The lesson is to read the puzzle instructions carefully and avoid solving more general problems.
What hit me was stupid, but also not covered in the example. It was rather implied and obvious from the example, though.
SPOILER ALERT
In my mistaken implementation `one2three1` would find "1, 2, 3" but not the second case of 1. Now, while the description never explicitly mentioned this, it's still obvious that it should be "11" and not `13`. Though my example, derived by TDD-ing from the example, gave `11`.
Only after I diffed my output with that of a known working solution did I find a few lines (there were several of them, though not that much) that made my issue clear: I missed the second case of a number appearing. So "one1one1one" in my solution would only find the first one.
Re: Advent of Code 2023 is nigh
#250I think I’d like to try this year’s in a language I haven’t touched before. What languages should I consider if I want something paradigmatically different from Go, Python, etc?
For me, it's functional coding. I find it fun to write as much as possible as filter/map/reduce operations with no mutations. I end up solving problems in a different way than I would in a non-functional language, which I think is good learning.
For me the language of choice is Kotlin, which strictly isn't functional. But it has a good stdlib and syntax for functional coding, so I just restrain myself and use escape hatches when needed. But any functional language would be nice, like Haskell or Clojure etc.