Beta
RangeSet
19wthit56
Loading description...
Algorithms
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Duplicate of at least 2 other kata's about ranges. And those kata's are published, without any issues, and with added performance constraints.
The most naieve solutions pass this kata, making this kata no challenge at all.
Random tests are floating point numbers, but description says all numbers are integers. Btw floating point numbers are a horrible idea. How will you assess ranges that "meet" with truncation and rounding errors in floating points?
Hi,
The tests have to be rewritten one more time:
expect
, or the assertion message has to provide expected/actual values tooassertSimilar
The description needs a sweep too:
r.ranges == [1, 2] [4, 6] [8, 9]
-> this kind of thing has no meaning as a JS code.cheers
Great kata! Seems like your update invalidated every solution that was there :D
There is a mistake in description:
r.add(4, 6); // . 2 3 4 . . . . .
( should ber.add(2, 4)
? )Yeah, I knew it would, but couldn't be helped if the tests were actually going to make sense.
Thanks for the heads-up. I've fixed this now.
Huge update! There was a lot of problems with the description, the tests, and even my own solution. Looks like all the existing solutions have been made invalid by the more complete tests, unfortunately. But you should still be able to access the code, if you're interested in tweaking your solution to fit the revised tests.
As far as I can tell, the spec hasn't changed apart from cutting out some of the stuff that wasn't necessary (eg. invalid argument handling). All the functionality should be the same. All that's changed are the tests.
Description consistently specifies "numbers". Is there testing with numbers other than integers? If not, might as well specify integers.
Kata IMO goes too far in requiring certain internals. If I can make
.test()
behave correctly, why should.ranges
be what you think it should be? It must apparently even be sorted a certain way. Why not leave that to solver?Example tests would be nice.
Maybe I'd do it differently today. At the time, there were effectively two tasks:
I've added a smattering of float tests.
I'm in the process of adding example tests.
Thanks for your feedback!
I've actually uncovered some serious bugs with my solution, and some gaps in the tests themselves. I'm thinking I might overhaul things soon...
Huge update to this kata!
Needs random tests and much bigger possible range.
Huge update to this kata!
Descriptions:
But this case is not tested at all.
I'm going to overhaul things soon. Thanks for your feedback.
Huge update to this kata!
This comment has been hidden.
Ah-- thanks for that. Fixed.
Cool, thanks :)
Huge update to this kata!
Nice kata, wthit; I enjoyed doing it, but there were a few oddities that initially led to some major confusion for me:
ranges
array says it should contain "range objects" which I thought meant instances of theRange
class (especially since later in the kata description the phrase "range object" is used to refer to aRange
instance),from
andto
arguments, the same properties that should be on the "range objects" in theranges
array,ranges
array is on the prototype instead of initialized in the constructor, andRange
.The above all led me to think that the
ranges
array was some kind of weird class-wide array, instances ofRange
were the range objects in that array, and each instance ofRange
was supposed to add itself to that array.Obviously that doesn't make sense, and this was a bit of a derp moment for me, but I do think the kata could be made clearer if:
ranges
array is initialized in the constructor instead of on the prototype,Ranges
to reflect that it contains multiple ranges, andfrom
andto
parameters, it optionally accepted anotherRanges
instance to initialize itself with (by copying the ranges from the given instance).I think #1 is a must-fix, but the other two are a bit more opinionated, borne of my experience above, so it's up to you!
from
andto
to the constructor, it sets everything up, and then does the exact sameadd
operation as would be performed byrangeInstance.add(from, to)
.I hope my changes have made things clearer and more intuitive?
Yeah, I think it's better now. Thanks for your time!
Huge update to this kata!