Hi Roland, Op vrijdag 11 december 2015 11:42:34 UTC+1 schreef rkuhn: > > Hi Merlijn, > > The intuition is that the union of the output sequences should contain all > elements that are selected by the step and window parameters, but they need > to be present only once. >
Clear, that nicely expresses what I observed, but couldn't find the words for myself. I can see the sense in implementing it the same way as Seq.sliding (even though that makes me question Seq.sliding instead. But I guess this isn't the place to discuss that) > 1. test(10, 2, 6) = List(Vector(0, 1), Vector(6, 7), Vector(6, 7, 8, > 9)) - Wait, what? My expectation: List(Vector(0, 1), Vector(6, 7)) > > > Yes, here your expectation is correct and matches Seq.sliding, i.e. we > have a bug. Would you please file a ticket? > Sure, and thanks a lot for your fast response! > > Thanks, > > Roland > > Now 1 and 2 are clearly as documented, and in line with what I expect. > Increment gets respected, window-size may be reduced if no more elements > are available. In scenario 3 however, a different behaviour pops up: in > general it seems to favour respecting window-size over increment in many > cases (my closest approximation of when it happens: window < count && step > = 1) > > If your use case is like mine, this is a problem. I simply wanted a 1-1 > mapping between elements from source to sink, but modify each value > according to some function that can take the next value in the stream as > well. Given that you only propagate the current value on the stream, and > not the one 'peeked ahead' at (to prevent duplicate values in your output), > you will lose your final value in finite streams. I am less certain this is > a bug, it looks like this 'fitting windows over a stream with given steps' > may be useful in some cases, and therefore more of a design choice, I'm > interested to hear what you think. > > I also encountered case 4, however, when trying to figure out what sliding > actually does. This one seems clearly wrong to me, neither increment (we > see 6 two times), nor window-size gets respected, neither in a documented > or intuitive way. (informally, it seems to happen when the next step > surpasses the last value on the stream, but there were still values on the > stream that weren't consumed in the previous window) I don't file it as a > bug as of yet though, because I'm still interested in what you find the > correct behaviour for this case. > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
