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