6 kyu
Multirange iterator
Loading description...
Iterators
Fundamentals
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.
Nice kata, although something should be done to avoid brute-forcing it.
python new test framework is required. updated in this fork
approved by someone.
python tests are generating a warning:
fixed in latest fork.
very nice kata!, good for building concepts!
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
Eugene-katsevman, how about, for instance, (2, 0, 3) test case (theoretically)? Now some solutions return [] for it (for example, my second solution), some - a tuple ('0' is excluded, like in my first solution, it seems doubtful). Don't you think that we need certainty? Which option is more correct in your opinion? How about to add such test? And to my mind, description would be better with clarification on the possible length of the input tuple. Anyway, thanks for nice kata!
Thanks for the suggestion! I've clarified the task a bit. A generator should be returned, not a list nor tuple. All current solutions still pass, though. I don't know if knowing possible input tuple length be any help when solving this kata. We easely get a combinatorial explosion there and long inputs couldn't be even tested IMHO. You're welcome!
Probably, I put it not clear, sorry. I meant not type of returned data, but it's content. In potential test case with (2, 0, 3), should we return something EMPTY (empty list, e.g.) or we should combine the non-zero data ([(0, 0), (0, 1), ...(1, 2)])? Tuple's length was my second suggestion ;) After thinking a bit, I agree with you, it is not necessary.
If any of params is 0, we have to return an empty iterator. This case is tested in first example
May be it should have been expressed in some other way.
Thanks for clarification! Unfortunately, as a result of an error on codewars server, my wrong solution, with tuple output, was saved as 'completed' in my profile, and it puzzled me.
It's not a good idea to override a built-in function with your own one with the same name (
iter
).changed to multiiter completely forgot about this built-in, thanks
Problem in the random tests
fixed. Please try again