Hi.
Reviving this thread following a new feature request:
https://issues.apache.org/jira/browse/RNG-19
IMHO, the request departs from the initial goal (and, hence
the design "requirements" on which the current code is based).
As I suggested previously on this list, I'm going to request
a new "git" repository for implementing utilities based on
random generators.
First candidates are:
* Non-uniform deviates (i.e. the samplers now defined in
Commons Math's "o.a.c.math4.distribution" package),
* Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
* Data generation (e.g. random strings, currently defined in
Commons Math's "o.a.c.m.random.RandomUtils"),
* Syntactic sugar (e.g. strongly-type factory methods, as
suggested by Emmanuel during the RC1 vote),
* Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
Thus, "RNG Utils" would have a much less tightened scope, allowing
for experimenting with user-requested codes.[1][2]
Independently, I'm also wondering about removing the "JDK" element
from the "o.a.c.rng.RandomSource" enum.
Rationale is that this RNG should not be used.[3]
Once the LCG family of generators is available[4], the algorithm
provided by the JDK can be emulated.[5]
WDYT?
Regards,
Gilles
[1] Thus avoiding any impact on the stability of "Commons RNG" as a
simple, no-dependency, repository of PRNG algorithms ported to
Java (and usable as such).
[2] I'd also suggest to copy/move to that new component the related
utilities currently defined in Commons Lang.
[3] Users that _want_ to use "java.util.Random" for some reason will
probably be better off using it directly.
[4] https://issues.apache.org/jira/browse/RNG-16
[5] To be confirmed by a unit test...
On Wed, 21 Sep 2016 17:27:35 +0200, Emmanuel Bourg wrote:
Le 21/09/2016 à 14:46, Gilles a écrit :
If we want "Commons RNG" to be a repository of all
generators that exist out there, irrespective of their
known weaknesses, it's fine; but we should be careful to
not let casual users just pick one of the implementations
on the premise that the library focuses on high quality
generators.
I think it's fine to have weaker implementations as long as they are
properly documented with the necessary warnings. There aren't that
many
algorithms anyway, we'll quickly have the interesting ones.
I have no issue with adding any new implementation,[4]
on the conditions that it comes with
1. a unit test where the output (say, a few hundred
numbers) of "Commons RNG" is compared against a
"reference" implementation,[5]
2. the outputs of the "RandomStressTester"[6] piping
from the "Dieharder" and "TU01/BigCrush" actual
stress test suites.[7]
Sounds fair
[1] Emmanuel, if you don't mind, we'd thus set the JIRA
issue "type" to "wish" rather than "improvement".
As you want, that doesn't make a big difference. It could even
qualify
for the "New Feature" type.
[2] https://xkcd.com/221/
Now I'm tempted to implement a XKCDRandomGenerator just for fun :)
[3] Up to now, I had assumed that no known-to-be-bad
generators would be part of "Commons RNG" (except
"JDK", for reference purposes).
Note that as time goes some generators will be supplanted by better
ones, so Commons RNG will inevitably contain implementations weaker
than
the then current state of the art.
[4] It is not a problem to wait another couple of weeks
for the additional code, before releasing 1.0.
Ok, I can try implementing LCGs then.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
