It’s not a good sign that this meme appeared on day 1 already…
It’s great! I’ve had community members point me in the right direction after already “solving” it incorrectly. It really makes you think about it. You have to expand your test cases and really come up with a better solution.
Not to say it isn’t difficult especially if you expect the problem to be described perfectly accurately.
I don’t need a perfect instruction set, but dang if the examples couldn’t be better sometimes. Like
sixteen
was in there to show it only counted for 6, but nothing with overlapping text.The example for me immediately showed my overlap bug with “eightwo”. There aren’t too many other ways to make this ten words overlap. 🙂
The problem is the example is actually
eightwothree
which comes out as83
so if you replace from start to finish the example passes but the solution is incorrect.At this point you’re just complaining that the edge case is not highlighted in red.
I think it’s the right amount of pointers to make you aware of the issue without straight up telling you.
I’m not really sure how to interpret your comment but I’ll try my best. The edge case that causes some solutions to fail does not have any definition on how to handle it on the problem page. In other words, it does not state anywhere whether the correct interpretation of
1threeight
is meant to be18
or13
. If your solution replaces the words to numbers from left to right you end up with13
as the value but it’s meant to be18
.The example answers don’t cover this but you will realise something is wrong if you run it against your full problem. Community has been very helpful on providing pointers.
Just don’t replace, or replace only the first letter with the numeral
You can’t just replace the first letter either, because depending on the order of your replacements, you could be replacing the end of another number. (Encountered this exact problem trying to optimize my solution.)
I replaced the second letter, none of them overlap 2 letters.
Clever
As long as you replace any spelled out numbers from left to right it should work
2oneight
- if you replace from left to right you get21ight
or21
. This doesn’t work for part 2 as the answer should br28
.
I’ve solved part 2 multiple times now, but small intricacies keep popping up every time.
I’m stuck on one of these intricacies now! I saw some of the ideas on how other people did it but i honestly have no clue what i did wrong. Got any tricky examples to share?
I just solved it. I printed every set of integers in the format “Result: [theTwoDigits], from string: [inputString]” and mannually checked all of them. Eventually found the edge case that was causing troubles. It was a typo.
Oh god, sorry to hear that 😅i’m feeling desperate enough to try that, i just wrote a different implementation and i get the same (wrong) result. At this point I just want to know what i misunderstood or mistyped cuz its driving me crazy
The bug is some strings can have overlapping characters. onEight threEight fivEight. There are more cases. So if you do a search and replace your string becomes 1ight 3ight and the second number does not get found.
Possible fixes: Search and replace and add the extra letter: oneEigh then search and replace. Search and replace words to numbers but put some extra letters in just in case.
Thanks, I managed to find the culprit in the end however - I was using a forward-look of 5 characters for finding if it matches a word so in a string of a3two for example, it would register the two before the 3. It was an easy fix once i found the issue.
Those overlapping spelled out numbers were rough
It was for sure to catch people that were taking the easy route and using a replace. I had to rework my solution to get the start positions for the matches. That method made both parts easy to get together.
I was having a bitch of a time with day 1’s part 2 until someone pointed out that sometimes two numbers share a first/last letter (eightwo).
deleted by creator
its relatively fine, just harder than past day 1s and has cases that trip people up
I managed the overlap logic just fine (if in a clumsy way), but spent over an hour trying to debug my crappy parser-combinator code when the issue all along was a mis-spelling in my lookup table.