On Mon, Sep 26, 2016 at 6:21 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote: > >> I would keep the JDK source. My reasoning being: >> >> 1. Users that want to use java.util.Random would not be able to use some >> or >> all of the RNG Utils code as the later will probably relay on RandomSource >> instances. >> > > I don't understand the above. > Could you provide an example of what should be, but won't > be possible? > > I misspoke when I stated RandomSource. The RNG Utils code will probably rely on UniformRandomProvider as its engine for random numbers. So, if I wanted to use java.util.Random as the engine I was thinking to use the JDK random source to create the equivalent UniformRandomProvider. I believe what you are suggesting is if I wanted OOTB java.util.Random behavior I would create the equivalent LCG based UniformRandomProvider (once said functionality is available in commons-rng). I guess that is acceptable if such a UniformRandomProvider creation is in the form of a convenience, factory method so I am not required to know the correct LCG parameters to use. 2. With LCGs the current Random implementation provided by Oracle could >> possibly be emulated by commons-rng. However, there is no guarantee the >> current implementation is used by all JDKs. >> > > There is; the generator definition is part of the API. > > And APIs are subject to change, albeit not very likely with the OOTB implementation of java.util.Random. So, if commons-rng is going to provide a UniformRandomProvider that behaves like java.util.Random, we are accepting the maintenance of said UniformRandomProvider should the java.util.Random implementation ever change. Since, the likelihood of java.util.Random ever changing is remote, using an equivalent LCG based UniformRandomProvider is probably acceptable as well since the probably maintenance cost is minute. With that said, I started thinking a bridge to go between the two engines, UniformRandomProvider and java.util.Random, might be beneficial. For third parties that have implemented java.util.Random subclasses, it would be nice to provide the means to easily adapt their Random implementation to a UniformRandomProvider so it can be used in commons-rng related code. Conversely, for third parties that use java.util.Random instances, it would be nice to easily adapt a UniformRandomProvider to a Random so the commons-rng generators could be used.
