commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] "BitsStreamGenerator" as base class for all RNGs (Was: New base class for all RNGs)
Date Sun, 27 Dec 2015 13:51:25 GMT
On Sun, 27 Dec 2015 12:48:08 +0100, Gilles wrote:
> 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.
>

In addition to points (1) and (2) above, we should discuss the
following one.

(3)
Deprecate the "setSeed" methods (and also remove them from the
"RandomGenerator" interface).
The rationale is that they typically provide information for a 
constructor;
they invalidate the previous state of the instance and imply the same
computation as is performed at construction.
[The only task not repeated by "setSeed" is the array(s) allocation.]

I thus propose that we use the fluent API, as we agreed to do in 
general,
for the RNGs too. [I.e. a method "withSeed" will create a new 
instance.]

This will also solve the potential security problem of having public 
methods
called from the constructor.

Any objection?

Gilles


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


Mime
View raw message