commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
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
Hi.

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

(1)
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.

(2)
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):

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

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

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

by

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

OK?

If so, I propose to still create a new "BaseRandomGenerator" class that 
will
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.



Gilles


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


Mime
View raw message