6 kyu
The range() function
2,053 of 2,140user5363957
Loading description...
Fundamentals
.avif)
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.
The case where there could be 3 arguments, but step is 0 was the tricky part for me.
Having finished the kata, I don't think the edge case of step === 0 is explained properly. There's a single example but no explanation of where the solution comes from. You basically have to guess as to what the kata wants. I think the description should be edited to include some kind of instructions for when step is 0.
Who in their right mind would decide to make the first argument optional but not the next one?
If start is optional and not stop, then the proper signature should be range(stop, start = 0, step = 1).
Also the behavior for step = 0 or start > stop make zero sense to me.
It looks very similar to the
rangefunction from python to me (excluding the step = 0 case). So I don't think it is that strange to want such behavior.Sorry, but while the Python
rangefunction has weird semantics, it does not in any way justify a signature likefunction(optional_argument, required_argument, optional_argument)...It is very strange to want a function to have optional arguments that do not come last.
Say I call
range(a, b)... Is the first optional argument omitted? Or the third one? How would you tell?Just because the Python
rangefunction is messed up and makes very little sense and cannot be improved because retro-compatibility is vital... does not give this kata any value. Especially with other languages in the mix.Say I really go out on a limb and make language semantics allowing ANY argument to be optional.... Then I could write this:
my_wonderful_function = (optional_arg1 = default_arg1, required_arg2, optional_arg3 = default_arg3) {...}But then what if someone callsmy_wonderful_function(0, 2)? Is itarg1 = 0andarg2 = 2, orarg2 = 0andarg3 = 2?Optional parameters which go before required parameters make NO sense. Even less so in a language like JavaScript which treats
undefined,null,0,'', and[]as similar unless you ask for a super strict comparison.TL;DNR: if the point was to reproduce the very weird behavior of Python's
rangefunction, maybe it should have been restricted to Python (or forgotten entirely and never made into a kata).Optional arguments always come last.
Why would you replicate Python's range in Python? It's already a built-in there. That makes less sense to me. Yes, I agree it's confusing, but you only can assume if you receive two arguments, they're the first 2, and never the last 2 (just like Python's range).
Why replicate Python's range in any language at all? Especially given its behavior is nonsensical. I've seen plenty of katas about implementing built-in features (without using the existing ones of course) so your question is not as rethorical as you seem to believe. Have a nice day.
if step equals zero, how can "if(step == 0") not work??? it's just annoying
it just ignores the "if(step == 0)" case
What's this?
Use logical operators.
But why it just ignores the 'if(step == 0)'?!?!
when step equals 0, it just ignores console.log(step WHY?
I don't know what you mean, you have this line:
if(step == 0){return 2}and one test fails with this error message:Test failed for range(0,2,0): expected 2 to deeply equal [ 0, 0 ]so it's not ignoring it as you say it does.i just understood what was the problem, thx
Why should the function range(1,5,0) return [1,1,1,1]? (four elements).
But the function range(0,2,0) should return [0,0]?(two elements)
Of course, if you trust the tests :)
Please explain if I'm wrong.
Read the answer to the post below yours.
Tests wrong, I occurred same issue,
Contradiction.
This is a wrong TAKA! at least it with wrong submit tests. Please update them.
I really comfuse with param stop. As description it mean the interger in array's max value. but in step 0 case like range([1, 4, 0]) return [1, 1, 1] if seems like means the max index of array. For the first understanding logic, step 0 will never stop, becuz the value of the interger won't touch the max. If understand 'stop' to max index, case range([1, 11, 1]) return [1, 2, 3, 4 ..., 10], will also wrong. Is there some misunderstanding for me? or this one has issue?
start- the start of the range (inclusive)stop- the end of the range (exclusive)step- the difference between consecutive numbers in the rangeEdge case when
step = 0, it should returnstartrepeatedstop - starttimesI got it, but when step === 0, stop's defination changed, it's strange. a value changes it's defination depande on other params' value
submit test wrong: range(1,5,0) test right answer is [1,1,1,1] (stop - 1) times loop range(0,2,0) test right answer is [0,0] (stop) times loop
any one can fix it?
What's to fix? The tests are fine (at least, according to examples on the description):
Description could be better tho.
Node 14
approved
Thanks :)
Nice kyu. Once you understand how step 0 should be done its not that hard... :)
It seams that random tests are incorrect for Go.
I got for instance:
With start = 7, end = 21, step = 10 Expected <[]int | len:2, cap:2>: [7, 17] to equal <[]int | len:1, cap:1>: [7]
The actual solution is correct, not the expected one.
You are right. I've just updated the tests, it should be fixed. Let me know here if you still have problems.
Go translation
approved
Description did not mention at any point what should be done if no arguments at all are passed to
range(), but this is tested in the random tests.Yeah struggling with this right now. What's the logic behind range(10) returning an array from 0-9? If you're going to test arbitrary test cases define the result you're looking for. I can pass 3/4 tests.
cannot happen anymore in JS
the worst description I've ever seen smfh... this one must be removed
Ruby translation
No random tests.
Added.
Going to not complete this on purpose :) Bad kata i think.
How this kata got out of beta is beyond me.
The description clearly states: Returns a list of integers from start to stop, incremented (or decremented) by step, exclusive.
In that case, (1,4,0) should return an infinite list of 1's, since by incrementing 1 by 0 you will never reach 4.
Next: out of the three parameters, two are optional. The description never explains what happens when the function receives two parameters. Is it start, stop ? Or is it stop, step ? One shouldn't do detective work on the test cases to find out the answer to that one.
If I could down vote this, I would.
Came here to say this.
In all the other options the increment determines how many items are returned in the array. Giving three 1s is just pretending that you're incrementing by 1 but not stepping up. Where does the increment of 1 come from?
Really shouldn't have optional arguments first. Granted, in this particular case, we could work around it. Still. Let's think about this. range(10,1) could mean end 10 step 1([0,1,2,3,4,5,6,7,8,9]), or start 10 end 1 ([])
What if it were something else? For example createContact([someNumber],deskPhoneNumber,[someOtherNumber]); Note: number only, no dashes. I pass two parameters. Tell me which numbers they are?
Also agreeing, (1,4,0) == [1,1,1]??
range(1, 4, 0) => [1,1,1]
Wait. What?
Imho it's "Process was terminated. It took longer than 6000ms to complete".
This comment has been hidden.
Like the others i disagree with the outcome of the 0 step test. If something does not incriment each step then it would create an infinite loop. If you meant that the step should incriment 1 as a default value if nothign was set or if it was set to 0 that was not stated, but even if that was the case in my head it still should not return 1,1,1 but 1,2,3. Could you explain more why it should return this?
I could add in an extra part to my code so it would read the step as 0 but still incriment as 1 by default and print out the 1,1,1 but like I said in my head thats not how it should work.
A little dissapointed with this Kata, overall it has a very good aim. However it is contradictory
range(10, 0); // /!\ note that the end is before the start => [] range(0, -10, -1); => [0, -1, -2, -3, -4, -5, -6, -7, -8, -9] Shouldnt this also return [] considering 0 comes before -10?
I think the description needs some work.
/!\ note that the step is 0and/!\ note that the end is before the startdon't help the coder understand what behaviour is expected in these situations. Also, I'm not sure the result from a 0-step call makes much sense. I guess it's some edge-case to mimic some implementation, but this should be explicitly explained.Need to reread the description, but I would suspect some infinite loops from my current solution. Would be good to specify which language's range function you're specifying.
Really like dpellier solution!
why is this the expected behavior?
If you have no increment (step = 0), how do you define the amount of items? Sounds illogical to me.
This comment has been hidden.
I agree. This behaviour is entirely arbitrary.
My code has the following:
I was confounded by this too. If you are going to specify something for this case, specify throwing an exception.
Agreed, I ended up hard coding that particular case just because it made no sense for it to behave that way.
Indeed, you're right, thanks for pointing out this case. I've updated the description and the test cases as well. Thx.
Could you please mention in the description what is expected if step = 0. i'll mark it ready then. Nice kata anyway.
This comment has been hidden.
Indeed, you're right, thanks for pointing out this case. I've updated the description and the test cases as well. Thx.
imho, it is better to also mention it in the text, because I don't always read all examples if I think I got it. but that might just be my personal preference.
From now on, the case of the step 0, is specified in the description and in the example test cases. You can not miss it anymore :-)
Marked it as ready. Cheers.
Can you mention in the description that you should return the array after you've either:
endvalueDivided by Math.abs(step), right? But the rule is broken for step = 0 :)