#25 Default JDK based RandomEngine

[Anonymous]

Here is a thread safe implementation of a RandomEngine based on the JDK sampler. This implementation is thread safe and better than the RandomCMWC (at least in the MCMC sampler that I'm running).

~~~~
import java.util.concurrent.ThreadLocalRandom;

import jdistlib.rng.RandomEngine;

public class JDKRandomEngine extends RandomEngine {

@Override
public double nextGaussian() {
    return ThreadLocalRandom.current().nextGaussian();
}

@Override
public double nextDouble() {
    return ThreadLocalRandom.current().nextGaussian();
}

@Override
public float nextFloat() {
    return ThreadLocalRandom.current().nextFloat();
}

@Override
public int nextInt() {
    return ThreadLocalRandom.current().nextInt();
}

@Override
public int nextInt(int n) {
    return ThreadLocalRandom.current().nextInt(n);
}

@Override
public long nextLong() {
    return ThreadLocalRandom.current().nextLong();
}

@Override
public long nextLong(long l) {
    return ThreadLocalRandom.current().nextLong(l);
}

@Override
public RandomEngine clone() {
    return new JDKRandomEngine();
}

}

[Roby Joehanes]

A few questions:

1. How do you measure "better"? ThreadLocalRandom seems to use a simplistic Lehmer algorithm with a limited cycle (http://www.drdobbs.com/testing-random-number-generators-part-2/184403208). CMWC has much longer cycle.
2. How can you ensure thread-based repeatibility since setSeed is unsupported?
3. ThreadLocalRandom seems to be a local thread instance of random number generator. How is it different than, say, instantiating a Random object per thread?

Thanks!

[Anonymous]

Good point, better is a bad word.

1. In my case my MCMC sampler got more stable results with the default JDK than the CMWC but unfortunately I did not have time to examine exactly why. In the end the JDK was not good enough anyway so I re-designed the mersenne twister to be across thread safe, with a performance penalty of course.
2. You cannot. But in my case this was sacrificed in favour of speed and thread safety.
3. Hmm, mostly in the way I access it. In my case I have a static sampling class that shares one random object but is accessed from mutiple threads.

Cheers!

[Roby Joehanes]

Apologies for rather late reply, but I've been very busy. Further questions.

1. It's really hard to assess stability, especially with random numbers with small cycle (compared to CMWC or MT). The apparent stability may be due to repeating cycle. So, approximately how many random numbers did you generate in your MCMC sampler?
2. In scientific experiment, you are often required to reproduce your results---often to the exact figure. We know that parallel computing essentially put an unsurmountable obstacle towards that end since we cannot force the ordering of the threads. However, as far as single-thread repeatibility goes, you will need to enforce some level of repeatibility. I guess you can have this type of code if your result is largely invariant by the seed and the result is largely secondary.

Comment on #3: I'm not exactly sure how sharing one randomizer instance could prevent parallel problems, say, a race condition. But I guess in Lehmer's algorithm, it doesn't matter.

All in all, I am inclined to not include this code into the library. But I suppose other people could refer to this implementation if it suits their needs.