Re: [RNG] Scope of "Commons RNG"

Gilles Mon, 26 Sep 2016 16:38:38 -0700

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 usesome orall of the RNG Utils code as the later will probably relay onRandomSource
instances.


I don't understand the above.
Could you provide an example of what should be, but won't
be possible?

2. With LCGs the current Random implementation provided by Oraclecouldpossibly be emulated by commons-rng. However, there is no guaranteethe
current implementation is used by all JDKs.


There is; the generator definition is part of the API.

Also, there a no guarantee the
Oracle implement doesn't change in future versions of their JDK


I think there is for the same reason as above.

and change
to something that can not be emulated by commons-rng.


"RandomSource.JDK" does _not_ emulate "java.util.Random".
The only guarantee is that both provide the same sequences of
32-bits integers.
I.e. no such guarantee for any of the other "nextXxx" methods!
[See the docs.]

Regards,
Gilles

So, to give users more flexibility in choosing a RandomSource and tobe

resilient to Random change, I feel the JDK source is beneficial.

Brent

On Mon, Sep 26, 2016 at 11:33 AM, Gilles<gil...@harfang.homelinux.org>

wrote:

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 theyareproperly documented with the necessary warnings. There aren't thatmany

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 evenqualify

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 weakerthan

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

Re: [RNG] Scope of "Commons RNG"

Reply via email to