commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject [Math] "BitsStreamGenerator" as base class for all RNGs (Was: New base class for all RNGs)
Date Sun, 27 Dec 2015 11:48:08 GMT

>> [...]
>> BitStreamGenerator uses the more standard int next(int bits).  Note
>> that we have *no* internal direct implementations of
>> AbstractRandomGenerator, while BitStreamGenerator has worked very
>> nicely as a root for good PRNGs.
> Something implicit in "BitStreamGenerator": the maximum number of
> bits is 32 (cf. return type of "next(int)" and the ubiquitous use
> of hard-coded "32".
> What about the possibility of using a "long" as a building block
> for another family of RNG?
> Gilles
>> Therefore, I think for V4 it might actually be best to just drop
>> AbstractRandomGenerator.  Sorry I did not think of this before
>> responding above.
>> Phil

Do all RNG that are going to ever be implemented in CM based on a
"int next(int)" method?

If not, then we can have a problem as soon as there is another
way to provide the random bits.

Assuming that we only need
   int next(int bits)

I notice that the source of random bits does indeed creates an "int",
say "x", and then truncates it before returning:

   protected int next(int bits) {
     // Build "x"...
     return x >>> 32 - bits;

So, I believe that the actual basis for generating randomness should be
a "public abstract int nextInt()" method to be overridden by concrete
RNG producers (as "next(int)" currently is):

   public int nextInt() {
     // Build "x"...
     return x;

and the truncation should be performed inside the respective methods 
currently call "next(int)". [Which are all in "BitsStreamGenerator".]
For example: replace the current

   public float nextFloat() {
     return next(23) * 0x1.0p-23f;


   public float nextFloat() {
     return (nextInt() >>> 9) * 0x1.0p-23f;

And, as a bonus, this will avoid the unnecessary
   x >>> (32 - 32)
operation currently performed when calling "next(32)".


If so, I propose to still create a new "BaseRandomGenerator" class that 
be different from "BitsStreamGenerator" because of the above changes.

This class should be backported to MATH_3_X so that we can deprecate
"BitsStreamGenerator" in 3.6.


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

View raw message