[concurrency-interest] class SplittableRandom
peter.levart at gmail.com
Thu Jul 11 07:29:02 PDT 2013
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;
> 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:
<R, S> Stream<R> splitMap(S seed,
BiFunction<? super T, ? super S, ?
extends R> mapper);
Your example would then read:
List<List<Int>> a = ...;
sr -> sr.split(),
(list, sr) -> list.get(sr.nextInt(list.size()))
But I don't know if such API is usable in any other scenarios though.
> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the lambda-dev