Encounter order
Brian Goetz
brian.goetz at oracle.com
Fri Oct 26 06:04:23 PDT 2012
Its the same problem of sensibility that we get with ordinary reduce.
If we can only assume the reducer is associative, and we see that the
input source structurally has an encounter order, then reordering the
elements could result in the wrong answer. (i.e., it stands to reason
that stream.reduce(r) should produce the same result as
stream.reduceBy(e -> 1, r).get(1)).
On 10/26/2012 8:55 AM, Andrey Breslav wrote:
> People don't expect ordering of the *keys*, and that's fine. What I
>>>> was talking about was ordering of the values, since the Map returned
>>>> is a Map<K, Collection<V>>.
>>> Your reduceBy() looked like this:
>>>
>>> <U, W> Map<U, W> reduceBy(...)
>>>
>>> no collections anywhere. Was that a mistake?
>>
>> groupBy returns a Map<K,Collection<T>>.
>>
>> reduceBy returns a Map<K,W>, because instead of accumulating elements
>> in a K bucket and sticking them in a collection, we reduce all the
>> elements in the K bucket.
>>
>> For example:
>>
>> Map<Author, Document> longestDocByAuthor
>> = docs.reduceBy(Document::getAuthor,
>> (d1, d2) -> (d1.length() > d2.length() ? d1 : d2));
>>
> Yes. And my point was that thus no ordering considerations are
> applicable to the result of reduceBy. Or am I missing something?
More information about the lambda-libs-spec-experts
mailing list