commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [RNG] Scope of "Commons RNG"
Date Mon, 26 Sep 2016 23:21:08 GMT
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?

> 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.

> 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 to 
> be
> resilient to Random change, I feel the JDK source is beneficial.
>
> Brent
>
> On Mon, Sep 26, 2016 at 11:33 AM, Gilles 
> <gilles@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 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message