because it's not best practice. It's overcomplicating for the fun of getting a O(n) solution (and I suspect that, if I scrutinize this now, years after, I'd find it's not a true O(n))
So it's valuable/intersting, but probably not what you should aim for in prod (unless you need the perfs... But then lechevalier's is probably faster... Anyway).
I have limited numbers of random tests in JS and Haskell to 30, because I size tests by the square of their index, and I noticed too late that -1000 <= x <= 1000.
That restriction is pretty much useless, it doesn't make any material difference to solvers, and you could help me by not imposing arbitrary and artificial limits like that. There is just no need to specify a bound on coordinate values, as long as you keep values within safe Int limits ( which vary by language ).
Please don't change this kata! It's not that important. But please keep this in mind for subsequent kata. Do not impose limits unless it serves a purpose.
because it's not best practice. It's overcomplicating for the fun of getting a O(n) solution (and I suspect that, if I scrutinize this now, years after, I'd find it's not a true O(n))
So it's valuable/intersting, but probably not what you should aim for in prod (unless you need the perfs... But then lechevalier's is probably faster... Anyway).
I have limited numbers of random tests in JS and Haskell to
30, because I size tests by the square of their index, and I noticed too late that-1000 <= x <= 1000.That restriction is pretty much useless, it doesn't make any material difference to solvers, and you could help me by not imposing arbitrary and artificial limits like that. There is just no need to specify a bound on coordinate values, as long as you keep values within safe
Intlimits ( which vary by language ).Please don't change this kata! It's not that important. But please keep this in mind for subsequent kata. Do not impose limits unless it serves a purpose.
Thanks! The description is now much clearer.
123456781is not useful as an edge case.91is useful. The point is to truncate a multi-digit number in a correct consecutive sequence.And no, it's unnecessary to leave
int, and we should not do that.This test is out of bounds. And you can't just go changing the bound, because people rely on those bounds, and they interact with each other.
Added to Scala and CoffeeScript.
Okay. Added in this C++ fork.
So is this a case that you want to replace another case, or is it a case you want added? I didn't quite understand the wording
Nobody expects you to support translations to languages you don't know. But even if or when I'm not here, there will be people to help you with that.
That said, I probably won't be going away anytime soon.
I did change your description.
Do note I changed the description. Approve only if you agree with my changes.
Try this one
"Description cannot be approved, recent changes from related record must be merged first."
I'll fix that. The description was changed between the moment I started the translation and the moment I published it, and you get that message.
hit the "approve" button
Haskell translation