Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 27 Dec 2015 12:48:08 +0100
From: Gilles <gilles@harfang.homelinux.org>
To: <dev@commons.apache.org>
Subject: [Math] "BitsStreamGenerator" as base class for all RNGs (Was:  New
 base class for all RNGs)
In-Reply-To: <973d22673ddd25480afb911821dadfd4@scarlet.be>
References: <4741114c4f780fd7e503183346ac015c@scarlet.be>
 <567F1564.8000105@gmail.com> <973d22673ddd25480afb911821dadfd4@scarlet.be>
Message-ID: <26356794bf6f08a48ad19be20e792748@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: eir; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at eir
X-Virus-Status: Clean

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