2 kyu
Generator Functions
Loading description...
Iterators
Functional Programming
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.
Interesting task!
To me it's the opposite. I think this makes it more complex, because the first
next
call behaves differently from subsequent ones.Regarding this question: https://www.codewars.com/kata/59e7c7e5fc3c49d93f0000d3/discuss#605e6ee0983870002f0cfabb
This should be explained in the description. I was scrathing my head since the first time I saw this kata and wondered how to squeeze generators in a way they do not get in a way of each other into required API of
Flow
and could not come up with anything, just to read here that it's not necessary.The fact that this requirement does not have to be satisfied is counter-intuitive because now the kata relies on the fact that generators are not fully independent.
okay, I might have a brain fart and its possible I misread one thing and raised the issue.prematurely. If someone is able to confirm that the current API of
Flow
is sufficient to to create:next
methods, andnext
method interleave, then things are most probably ok and just resolve this issue.I will hopefully find some time soon to get back to the kata and try out some ideas which I think I missed before.
This comment has been hidden.
This comment has been hidden.
thanks, i've added your new tests. i've also added a note to the description warning that yielded values may be
null
(also, a bunch of existing solutions just got trashed by the null yields test... rip)
This comment has been hidden.
You could also test yielding null-values, with and without combining with yieldFrom.
When a generator is done, next() should return null. But if yielding null the generator might not be done.
this kata isn't really meant to test for multiple threads of execution, but i suspect using
static
variables to store generator-specific data will likely fail in cases with multiple generators anywaysIf the 'next' method of the generator takes a parameter, it's not clear to me how the flow should be managed.
The first call of 'next' should provide the initial value to the generator method and return that value -> ok. In case of the summation example 'next(10)' -> returns 10 -> 'total' = 10 Then the second call 'next(42)' -> the yield should take this parameter and provide it to the generator function: - so total becomes 10 + 42 = 52 - then, that second call should return 52. How is this possible if 'total' is a local variable inside the generator function and it got updated to 52 after the yield took place?
figuring out how to do that is part of the challenge of this kata.
Should it be possible for multiple generators to yield results in different threads that run in parallel?
no. you can assume that any calls to a generator object will be sequential
I think I see what you want to do here. Should using unrelated geneators running simultaneously in parallel threads work?
I don't this this kata requires that, but it would be nice anyway.
a good implementation probably should allow for unrelated generators to run in parallel threads, but this kata doesn't require or test for that
This is approvable.
I know JS and generator functions there; I don't know Java.
Is this really 1 or 2 kyu?
this kyu is basically just implementing coroutines from scratch using java's concurrency primitives of threads and locks.
personally, i don't think it's hard enough to justify a 1 kyu rating. i would recommend somewhere 2-3 kyu.
So we're not so much generating values as implementing cooperative multitasking from primitives? That sounds like 1 or 2 kyu ( 3 isn't even going to be an option I think, nobody voted 3 ).
that's right. i haven't really been active on codewars lately so i don't really have a good sense of how difficult each rating is any more
Nobody seems to have. Ranks have deflated like the Hindenburg in past years ..
Thanks!
I had a little look at this Kata today and have a solution that solves the sample tests fine, but times out for the final tests. I'm finding it a little hard to find the root of the problem, as I'm unable to debug the cases. Any help would be greatly appreciated!
Ok, just so I get this right. In the example test, there is this GeneratorFunction :
After the call to
next()
which returns"consectetur"
I need a new value to continue running the Generator.Fix it by adding this line in the sample tests.
(Also read as: I pass the final tests, but not the sample tests.)
fixed. thanks!
In the description it has the sample code
wich will result in Error:
It would be better to make the code like in the unit test
hence please update description.
fixed. thanks!
In JavaScript,
yield
is actually an operator, andyield total
is an expression.You're right, but I figured "statement" works better in this context because we're talking about
yield
being analogous to Java'sreturn
statement. It's just a thing I thought might make Java programmers that don't write JavaScript feel betterIf this works better for Java programmers, keep it this way.
I figured JavaScript
yield
as an operator, creating a value and returning a value as a side effect, might translate better to Javayield
as a function, also creating a value and returning a value as a side effect (in both cases, the respective values may be different from each other).Return OTOH does not create a value, it only returns one.
But as I said, just keep it this way.
Hi,
Could you provide another sample test using the Consumer and where the generator isn't infinite?
Done!
This comment has been hidden.
That would be a spoiler ;)
xp
;)
Tricky one. One thing that the compiler seems not happy with
total += Flow.yield(total);
in the example tests. //total += (int)Flow.yield(total);
will make it happy, but I do not know why IDEA tells that(int)
is redundant.My guess is that it has to do with type erasure of generics again (so after the static typecheck is completed, the type information of generics is lost).
yeah it's because Flow::yield's return type is the generic param I to it, which means the return type is inferred from the context of the call. Since the caller expects a primitive --
int
-- Java just goes "nope" and infers Object, which of course doesn't cast implicitly toint
. The two ways to fix are to either explicitly cast toint
or to explicitly specify types for<I, O>
I'll fix it tomorrow since I'm on my phone right now and CodeWars' mobile support is nonexistent right now.