On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
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.
If the need is to generate the same sequence of integers as would be
generated by "Random", then, indeed an LCG with the appropriate
settings
(multiplier, increment, modulus) should fill the bill.
A custom LCG would be instantiated with a call like
rng = RandomSource.create(RandomSource.LCG_SELECT, seed, multiplier,
increment, modulus);
and convenience shortcut would be provided as
rng = RandomSource.create(RandomSource.LCG_JDK, seed);
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.
If the implementation of "Random" changes, and the need is to produce
the same sequence (of 32-bits integers) as "Random", then using a
"fixed"
Commons RNG algo won't work since Commons RNG and JDK won't agree
either
for older or for newer Java versions.
If it is possible that the JDK API changes in that way, then that would
be a reason to keep "RandomSource.JDK".
But if the JDK API changes in such a way, it would also break existing
applications that rely on the definition of the RNG used in "Random".
I'd have supposed that the development policy of the JDK would not
allow it.
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.
Like method "asUniformRandomProvider" in
"o.a.c.math4.random.RandomUtils"
("master" branch)?
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.
That would be possible (but the bridge must be from "RandomSource",
not "UniformRandomProvider"): see class
"o.a.c.math4.random.RngAdaptor".
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
