-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
combine_latest emit_on behavior #48
Comments
In a corollary should we have an equivalent to |
good question. I think we may want to first go back and review existing streams. Here's
We've modified it by adding Consequently, should we start making figures for the methods here? I can go ahead and begin. We just need to agree the medium. I generally use inkscape. |
can you clarify about |
I am a very visual art challenged person (I can appreciate it, just not create it) so I'd say go ahead with whichever medium works for you, thank you! |
hehe same, but i guess i can get something started, later this weekend hopefully, as a PR. If we end up using it, we should remember to squash commits with image changes to save space... |
for |
Maybe a better view:
We may want the ability to specify lossless streams coming into the multi-stream nodes. So maybe |
Something like |
Here is an implemented example (in the event model) |
@ordirules you might look at tikz to make these examples, we may be able to make them with streams (which would mean that if/when we update the code the examples will also be updated) and then insert them into the docs. |
thanks, I used to use asymptote which I really like but it's probably out of date :-D. I'll take a look at this later. LaTEX is always a plus! |
Note that |
@CJ-Wright doesn't the name |
That's fair. I'm rather bad and at naming things, any suggestions? |
I agree on that - I think Edit: (General rumblings unrelated to topic) Something like is going to yield 1a, b3, which (to me) is unexpected and could throw out sense of order in your system |
@limx0 Can you clarify what you mean by "perfect fashion"? Putting the naming issues aside, would other people find something useful where one stream will be guaranteed to be emitted while combining it with another stream? |
By perfect fashion I mean; having multiple sources of data that emit elements at the (almost) exact same time and without fail in a way that your zip function continues to emit as intended. This is more of a practical issue than a library/theory note. What I mean is while
But in the wild, where your Edit: This is more of a caution for using external sources, if you have control over all of your inputs it's probably fine |
Yep, I'm sure they would. My general thought is leave |
I have some experiments where that is doable, especially where you know that the number of elements will be the same. # cumulative average
a = Stream()
b = scan(add, a)
c = scan(lambda x, y: x + 1, a, start=0)
d = zip(b, c)
e = map(divide, d)
for data in data_source:
a.emit(data) Edit: bug in scan lambda needs two args |
Maybe I should make a hybrid |
Also keen to have a
What about Edit: Nevermind I was thinking it did more of a product-like combination. I'm not 100% sure what your stream above ^^ is doing |
|
@mrocklin @ordirules Thoughts on a name? |
Just catching up. Actually, I think maybe if it's just for the use case you mentioned earlier with the diagram, it could be
would give:
as opposed to:
Which is just as you mentioned, I may have missed something. If yes, could you provide a use case and schematic? |
I'm somewhat slammed with Dask things this week. Sorry for going dark
recently. I'll probably continue to be quiet for the next couple days.
…On Thu, Aug 10, 2017 at 1:05 PM, Julien Lhermitte ***@***.***> wrote:
Just catching up. Actually, I think maybe if it's just for the use case
you mentioned earlier with the diagram, it could be
combined_latest(wait_first=True) or something. So:
s = Stream()
s2 = Stream()
s3 = s.combine_latest(s2, wait_first=True)
s3.map(print)
would give:
s1 : A--B------------C---------D-
s2 : -------1-----2---------3--4---
s3 : ------A1B1----C2-------D4-
as opposed to:
s1 : A--B------------C---------D-
s2 : -------1-----2---------3--4---
s3 (no wait) : ------b1--------C2-------D4-
Which is just as you mentioned, combine_latest, but with some buffering.
I may have missed something. If yes, could you provide a use case and
schematic?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszAr_x1HTOHTBTqMmPYLagbKFAFcDks5sWzhfgaJpZM4OuMJF>
.
|
I don't have too much preference one way or another (between creating a separate node and putting a flag on A name consensus would be nice too! |
Should we buffer the
combine_latest
emit_on
stream?Context
Consider the following situation, we have two streams
a
andb
. We are going to usecombine_latest
to combine them, with an emit only ona
. 5 entries come down froma
then one comes down fromb
then one froma
. Due to the lack of data fromb
none of the 5 initiala
entries have been emitted since theb
was missing. Now that we haveb
data do we expect it to emit 6 times (which would require the buffering of theemit_on
stream or only once (which may violate the idea of theemit_on
stream always emitting)?@mrocklin @ordirules @danielballan
The text was updated successfully, but these errors were encountered: