skip/limit in parallel context

[Paul Sandoz]

On Dec 13, 2012, at 3:20 PM, "Mallwitz, Christian" <christian.mallwitz at commerzbank.com> wrote:

> Hi Paul,
> 
> Ah, this helps and it even produces the expected result :-)
> 
> Your explaination though gets me confused when looking at the javadoc: On java.util.stream.Stream:
> 
> <U> U reduce(U base, Combiner<U,T,U> reducer, BinaryOperator<U> combiner)
> 
> the reducer (2. param) is a Combiner and the combiner (3. param) is the BinaryOperator ???
> 

I know :-) in the latest source Combiner was replaced with BiFunction:

    <U> U reduce(U base, BiFunction<U,T,U> reducer, BinaryOperator<U> combiner);


> I would have at least expect my BinaryOperator '(left, right) -> left + 1L ' from the sequential operation to go to the 3rd parameter.
> 

Note that we are currently hashing out a major improvement to this area so stay tuned.


> 
> Additionally, I would assume calling "reduce(T base, BinaryOperator<T> op)" on a parallel stream would never make sense, would it?

It can for a commutative function such as sum, or finding the min or max value.


> Vice versa: calling "reduce(U base, Combiner<U,T,U> reducer, BinaryOperator<U> combiner)" should be reserved for parallel streams as there is no 'combining' on a serial stream? 
> 

I would not be inclined to restrict it use for parallel evaluation only and requiring developers to do "if (s.isParallel())".

When using reduce (or fold) one is obligated to consider certain properties of the function. We need to make that obligation easier to understand.

Paul.