commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] New base class for all RNGs
Date Sat, 26 Dec 2015 23:52:03 GMT
On Sat, 26 Dec 2015 15:32:04 -0700, Phil Steitz wrote:
> On 12/26/15 10:52 AM, Gilles wrote:
>> Hi.
>> There are currently two RNG hierarchies: "AbstractRandomGenerator"
>> and
>> "BitsStreamGenerator". They both implement the "RandomGenerator"
>> interface.
>> In both classes, the "nextBytes(byte[])" method generates 4 bytes
>> at a time.
>> Thus, functionally the code is the same, even though one calls
>> "nextInt" and
>> the other "next(32)" (which is what its "nextInt()" also calls).
>> I propose that a new base class implements "nextBytes" (and
>> perhaps other
>> methods that can be coded in a generic way):
>> Are there objections?
> Hey sorry I did not think to raise this possibility before, but it
> could be we are letting archeaology complicate design here.  In 4.0
> we can clean up what I think may be an early mistake.  The reason
> that we have two hierarchies here is that AbstractRandomGenerator
> predates BitStreamGenerator.  The AbstractRandomGenerator somewhat
> iconoclastically basis things on nextDouble() while
> 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?


> 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

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

View raw message