4 ms·

Ok, I'll be that guy... what edge case? My part 2 was 4-line addition to part 1 (see code below, if inappropriate let me know and I'll remove it), and it worke

Ok, I'll be that guy... what edge case? My part 2 was 4-line addition to part 1 (see code below, if inappropriate let me know and I'll remove it), and it worked first try. On the other hand, I made a mistake in part one and got it right only on a second attempt... (definition of nums[] omitted) for (j = 1; j < 10; j++) if (!strncmp(&buf[i], nums[j], strlen(nums[j]))) buf[i] = j + '0';

Frummy 3y ago
Edge cases such as "1oneight", "3sevenine", "sevenine3" (I made these up to highlight)
- mqus 3y ago
  Thanks! I thought I had the most straight-forward code there is and there were no edge cases that I hit. But I didn't use regex or something, just manual pattern matching like gp. Imho regexes are overused for such stuff, precisely because they might do a lot of things you don't think about and are usually a lot slower than manually implementing what you want.
- sokoloff 3y ago
  I’d wager that most implementations would be fine on “sevenine3”, as they’d likely get 73 for the row, whether or not they found the 9.
  - Frummy 3y ago
    If they have functions that for example reads from forward then backward or vice versa while changing the structure of the row, one test will pass but the other won't. It's a lot of rows in the input and it took a lot of time for me personally to debug to understand what went wrong
  - criddell 3y ago
    How about just "sevenine"?
sixothree 3y ago
I don't understand getting hit by an edge case either. Here's mine using Linq. var bestFirstValue = possibleValues .Where(x => currentLine.IndexOf(x.searchString) != -1) .OrderBy(x => currentLine.IndexOf(x.searchString)) .First() .intValue;
berkes 3y ago
The most obvious edge-case was mentioned by other siblings. My "edge case" is probably not really even an edge-case though. SPOILER ALERT --- My implementation stopped looking when it found a number. So "one2one" or "1twone" and so on, would find the numbers "1,2" and not "1,2,1". There were no examples where a number appeared multiple times in a line AND this affected the first-last pair. So e.g. abc1ninexyz841 would result in 14 in my case but should've been 11. Again: it's rather implied and quite obvious if you interpret the description as human, but I worked at it from TDD, and the example missed this situation and the actual input had only a relative few of them, so debugging was hard.

Frummy 3y ago

Edge cases such as "1oneight", "3sevenine", "sevenine3" (I made these up to highlight)

mqus 3y ago
Thanks! I thought I had the most straight-forward code there is and there were no edge cases that I hit. But I didn't use regex or something, just manual pattern matching like gp. Imho regexes are overused for such stuff, precisely because they might do a lot of things you don't think about and are usually a lot slower than manually implementing what you want.
sokoloff 3y ago
I’d wager that most implementations would be fine on “sevenine3”, as they’d likely get 73 for the row, whether or not they found the 9.
- Frummy 3y ago
  If they have functions that for example reads from forward then backward or vice versa while changing the structure of the row, one test will pass but the other won't. It's a lot of rows in the input and it took a lot of time for me personally to debug to understand what went wrong
- criddell 3y ago
  How about just "sevenine"?

sixothree 3y ago

I don't understand getting hit by an edge case either. Here's mine using Linq. var bestFirstValue = possibleValues .Where(x => currentLine.IndexOf(x.searchString) != -1) .OrderBy(x => currentLine.IndexOf(x.searchString)) .First() .intValue;

berkes 3y ago

The most obvious edge-case was mentioned by other siblings. My "edge case" is probably not really even an edge-case though. SPOILER ALERT --- My implementation stopped looking when it found a number. So "one2one" or "1twone" and so on, would find the numbers "1,2" and not "1,2,1". There were no examples where a number appeared multiple times in a line AND this affected the first-last pair. So e.g. abc1ninexyz841 would result in 14 in my case but should've been 11. Again: it's rather implied and quite obvious if you interpret the description as human, but I worked at it from TDD, and the example missed this situation and the actual input had only a relative few of them, so debugging was hard.