6 kyu
N in a row
65 of 77Yushi.py
Loading description...
Iterators
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.
In my opinion, my solution is quite intuitive, which was also the approach displayed in the description. Had I not read about the warning of implementing O(n^2) time complexity, I would have still done the exact same solution. To make the description slightly more concise, may I suggest condensing that section or removing it entirely?
Edit: nice kata btw :)
I just removed the entire Performance section. Looking at it now, 4 months later, it doesn't really say much; the test specifications should be enough for the users to draw their own conclusions.
To be honest, I was originally trying to timeout solutions like yours, but I think
80%of the time is spent creating the tests, so it's kind of hard to properly time the solutions. I guess this isn't, and it doesn't really need to be a performance kata.Also, I'm glad you liked the kata :)
completely unrelated to the kata, but to those who know, we want you back, jperm...
Jperm was great, but I can't say I prefer one over the other. If only people could exist as two beings at the same time...
Quite nice and funny kata.
JS translation
the example solution is not the fastest, but the reference solution is actually a lot better ( example solution runs in ~9 seconds; reference solution in ~3 ), so I hope solvers have a reasonable amount of time for their solution to run.
minor changes to the description, also because I did not bother to preload
iterator.take.Approved. Thanks for taking the time to translate this, I'm sure it wasn't the easiest.
Not that it matter much, but I'm curious as to why the reference soluion and example are different or run at different times. Does the reference take advantage of already knowing where it ends or something?
Also, nice one on giving the user more time, it's really annoying when you have to way 6 seconds for the reference solution to solve.
Forgot to mark the solution as resolved...
I don't get it, do I need to return
undefined(as in sample tests) ornull..cr@p. did I forget to update the sample tests again?
I did the description updates last, decided for
nullinstead ofundefinedto remain closer to Python, updated the Submit tests, but apparenty forgot to update the Sample tests ( again ).We apologise for the inconvenience. Please
Refresh( don't forget to save your code ).this never goes to infinity. there's always at least total left. given the comment, this may not be intentional. also, maximum is never < 0.
the random tests are heavily overengineered; they are a total pain in the neck to translate. can't that be done simpler?
It's been 3 months, I don't really remeber my intentions, but I'm pretty sure that when I wrote
maximum < 0, I meantmaximum - minimum - first < 0.On the tests being overengineered. Yeah, they probably are, I couldn't find a better one at the time. But no, there's no good reason, it was what I found that worked.
I could try to make it simpler or if you have something simpler in JS, I can translate it in Python before approving your translation.
I managed to translate it; I'm not aching to do a complete rewrite in JS.
I think testing never actually gets to infinite iterators, but there's fixed tests for that, the kata is approved without anyone complaining and the rating is good enough - let sleeping dogs lie.
I tested it and it doesn't seem to be generating infinite generators.
However, as you said, I'm not sure if it really is that big of a deal. Specifically hardcoding the fixed tests seems like much more work than it's worth and the infite part of the challenge isn't that big of a deal.
So let's leave it be then. I also don't really feel like or have the time to be rewriting this right now. I'll approve your tranlation.
Sorry, but it
s the worst description, that ive ever readFeel free to suggest a better one :)
man, this isn't your daddy's 6 kyu kata lol. good one tho.
Surprised to see people here who seem to understand the description. Big pass.
Wording it will always be hard, I was just hoping people would understand by the examples. If you have a better description, please share.
I got all info I needed from:
I watched the video and it clicked.
Apologies for my semi-tantrum: I was a bit disappointed with myself for publishing the worst solution ever to the collinearity kata and took it out on Yushi.
No worries mate, I have these all the time, Johan would be able to confirm it. I'm just glad you were able to understand it.
This is misleading information.
I think it's more correct to state O(n logn) or O(n log logn) is expected, and further optimization towards O(n) is not required.
Does
O(nlogn)pass? I haven't been able to come up with anything witb that complexity orO(nloglogn)to test. I feel like most algoriths fall intoO(n),O(n * total)andO(n ^ 2), out of those onlyO(n)passes.It just feels weird to say a time complexity noone could come up with is expected. Maybe just say
O(n * total)andO(n ^ 2)won't pass?Maybe you should state O(n) solutions are very likely to pass, and there is a small tolerance for slightly slower solutions to pass. The way it's written now, makes it seem O(n) is definately required, and perhaps some optimisation towards even faster solutions is required.
but... what would even a O(n log n) solution or alike look like, here?
=> just suppressing the end of the sentence in the description?
That's what I thought. I changed it to follow what @dfhwze said, but I'm not sure about it.
If anyone can suggest something, I'll be grateful
Kata can be approved. Tuning the performance description can still be done at a later stage, when this kata gets more attention by the general public ;)
Thanks dfhwze, much love mate :)
Are you sure the perf constraints are not too much tight? My solution seems to be one of the expected one, but it times out more than half the time.
Yeah, your solution really shouldn't timeout, I changed the tests, made them more lenient. You should pass consistently now.
The implementation of
first_nconsumes one extra element from the iterator. You can swap the order of theziparguments to avoid this.I was wondering why it was doing that, makes sense. I'm creating a copy of the iterator, so it shouldn't matter, but thanks for the advice, I'm changing it.
first_nto avoid leaking imports to solversThat should all be done
Could do with having fixed tests which expect
None.Would ideally cover all three cases of
len(placements) > n,len(placements) == n, andlen(placements) < n.Done, I added those cases into their own test thingy named 'Edge Cases', it's probably good to warn the user in this case.
There were a few that already did what you asked, but it's nice to cover everything.