[concurrency-interest] class SplittableRandom

[Oleksandr Otenko]

You've just re-invented applicative functor.

Put simply, given a lambda and a list of values produce a list of 
lambdas. Then given a list of lambdas and a list of values, pair up the 
elements in matching positions, and apply the lambdas to the matching 
elements to produce a list of values. If those values are lambdas, you 
can "zip" another list of values, etc. This way you can apply functions 
with multiple arguments to lists of arguments.

Think of scalar vector product, where you first need to apply 
multiplication (function with two arguments) to two vectors (two lists 
of arguments for the function) to produce products of corresponding 
coordinates.

The uses are many.

Alex

On 11/07/2013 15:29, Peter Levart wrote:
> On 07/11/2013 01:14 AM, Aaron Grunthal wrote:
>> Would this be of any use in a case like this?
>>
>> List<List<Int>> a;
>>
>> a.parallelStream().filter(...).map(e->e.get(random.nextInt(e.size()))).reduce(...) 
>>
>>
>> i.e. a filter, random sample, reduce chain?
>>
>> I don't see a way to basically use two (or N) streams (the source and 
>> the random numbers) and merge them in lockstep at one stage.
>>
>
> In the absence of Stream.join(), we would need something like the 
> following in the Stream API:
>
> Stream<T> {
>
>         <R, S> Stream<R> splitMap(S seed,
>                                   UnaryOperator<S> splitter,
>                                   BiFunction<? super T, ? super S, ? 
> extends R> mapper);
>
>
> Your example would then read:
>
> List<List<Int>> a = ...;
>
> a.parallelStream()
> .filter(...)
> .splitMap(
> new SplittableRandom(),
>         sr -> sr.split(),
> (list, sr) -> list.get(sr.nextInt(list.size()))
> )
> .reduce(...)
>
>
> But I don't know if such API is usable in any other scenarios though.
>
> Regards, Peter
>
>
>> On 10.07.2013 21:13, Doug Lea wrote:
>>> [Note: I'm also posting this on the openjdk core-libs-dev list.]
>>>
>>>
>>> We expect that using random numbers in parallel Stream computations
>>> will be common. (We know it is common in parallel computing in
>>> general.) But we had left support for it in an unsatisfactory state.
>>> If you want to create a stream of random numbers to drive a parallel
>>> computation, you'd choose among two options, neither of them providing
>>> what you probably want: (1) Use a stream based on a single shared
>>> java.util.Random object, in which case your program will encounter
>>> stunning slowdowns when run with many cores; or (2) Use a stream based
>>> on ThreadLocalRandom, which avoids contention, but gives you no
>>> control over the use or properties of the per-thread singleton Random
>>> object. While the ThreadLocalRandom option is great for many purposes,
>>> you wouldn't want to use it in, say, a high-quality Monte Carlo
>>> simulation.
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest