4 ms·

Warning: post contains spoilers, HN doesn't support spoiler text so continue reading at your peril. These edge cases are triggered by fundamentally approaching

• sokoloff 3y ago
  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.
  • rileymichael 3y ago
    That’s exactly what I pivoted to once I realized my naive replace wouldn’t work. That sort of moment is what makes AoC feel so rewarding in my opinion. impl fully showing the trick: https://github.com/rileymichael/aoc-2023/blob/master/src/main/kotlin/day1/Day1.kt https://github.com/rileymichael/aoc-2023/blob/master/src/mai...
  • Maxion 3y ago
    I have to say that this is a hacky approach but I love it!
• cybrox 3y ago
  I agree that one should take a step back at that point but how exactly is this the fundamentally wrong approach to the problem? Re-using the existing code where possible is the fundamentally right approach to the problem. It just so happens that in this case, there were edge cases that prevented this, so another approach had to be taken.
  • Diggsey 3y ago
    > Re-using the existing code where possible is the fundamentally right approach to the problem. Reusing code does not make something "fundamentally right approach". An implementation that actually does what the problem asks is a "fundamentally right approach". If you can reuse existing code in that implementation then that's a bonus. The problem is very clearly specified, so if you choose to implement something else hoping that it's "close enough" then that's on you...
  • codr7 3y ago
    Wasn't this more about reusing the regex? I mean, who said you had to use a regex to begin with?
• manojlds 3y ago
  > 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.
  • berkes 3y ago
    In my experience they are very much "actual business problems"-alike situations. 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?".
• williamcotton 3y ago
  Here's a snippet of a first attempt, which does not work: |> Array.map (fun s -> Regex(@"(one|two|three|four|five|six|seven|eight|nine|\d)").Matches(s)) |> Array.map (fun m -> m |> Seq.map (fun g -> g.Value) |> Seq.toList) And here's the correct code: |> Array.map (fun s -> Regex(@"(?=(one|two|three|four|five|six|seven|eight|nine|\d))").Matches(s)) |> Array.map (fun m -> m |> Seq.map (fun g -> g.Groups.[1].Value) |> Seq.toList) There's no "fundamental" difference between the two, rather, one uses a regex with positive lookahead and the other doesn't. The first approach was not operating under the assumption that there would be strings like "oneighth" at the end of a line. That's a detail and it only applies to one part of a functional pipeline!