commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Worden <>
Subject Re: [RNG] Scope of "Commons RNG"
Date Tue, 27 Sep 2016 02:23:24 GMT
On Mon, Sep 26, 2016 at 6:21 PM, Gilles <>

> 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

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message