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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
