commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] JDK "Random" and "BitsStreamGenerator"
Date Tue, 26 Jan 2016 13:23:55 GMT
On 1/26/16 6:10 AM, Phil Steitz wrote:
> On 1/26/16 1:47 AM, Luc Maisonobe wrote:
>> Le 26/01/2016 01:13, Gilles a écrit :
>>> Hi.
>> Hi Gilles,
>>> In CM, a base class "BitsStreamGenerator" contains methods for
>>> generating various primitive types from a bit source (to be
>>> implemented by subclasses by overriding the "next(int bits)"
>>> method).
>>> For example, to get a random "long" value, the following code
>>> is called:
>>> ---CUT---
>>>     public long nextLong() {
>>>         final long high  = ((long) next(32)) << 32;
>>>         final long  low  = (next(32)) & 0xffffffffL;
>>>         return high | low;
>>>     }
>>> ---CUT---
>>> If the bit source were provided by the JDK's "Random" class,
>>> is it assumed that the "long" value generated by the above
>>> code will always be equal to the "long" value generated by
>>> the call to JDK's "Random" class?
>> No. There is nothing said anywhere in the javadoc that would imply
>> one implementation of nextLong is the same as another implementation.
>> The only thing that user can exapect is that when they choose one
>> implementation, it is consistent, i.e. it is "random enough" and
>> "not biased". Two different implementations can fulfill these
>> requirements without producing the same sequence.
>>> In other words, how "standard" are the default implementations
>>> of the methods defined in "BitsStreamGenerator"?
>> I don't think there are any standard to abide by.
>>> And what are the compatibility requirements with respect to
>>> reproducibility of the sequences (between releases of the
>>> library)?
>> It's a grey zone, IMHO. It is nice to preserve reproducibility
>> as changing it changes the reference test cases with fixed seeds.
> Did the original test cases for the generators that came in with
> Mantissa come from external references?  If so, it would be good to
> keep them for at least the bit streams themselves so we can be sure
> that what we have implemented is the standard implementation of the
> algorithm.  If we leave the standard algorithms themselves behind,
> it's then on us to produce tests to verify lots of properties beyond
> just lack of bias and uniformity.
> Phil
>> On the other hand, too much compatibility really is a pain, we
>> feel it constantly, so I would say that as soon as we need to
>> change the sequence, we can just do it, and check all the tests
>> we know of (i.e. those of our own library) still pass and we
>> go forward.

Sorry, I mean to add that while (maybe a bit strangely) the JDK
commits to a specific long-from-bits recipe (see the javadoc for
j.u.Random#nextLong) we have never done that and I am OK with
changing that if we get better performance as long as uniformity
tests pass. 

>> best regards,
>> Luc
>>> Regards,
>>> Gilles
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message