commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
Subject Re: [Math] JDK "Random" and "BitsStreamGenerator"
Date Tue, 26 Jan 2016 08:47:20 GMT
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.
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.

best regards,
Luc

> 
> 
> Regards,
> Gilles
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message