On 12/26/15 4:07 PM, Gilles wrote: > 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): >>> https://issues.apache.org/jira/browse/MATH-1307 >>> >>> 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. > > Do you mean that "BitsStreamGenerator" can be the base class for > any 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. > > Hmm. > Should I wait for confirmation before scratching it? > > Then I have another question concerning "JDKRandomGenerator": it does > not fit in the hierarchy.
Right. I don't personally think it *has* to fit in the hierarchy. It exists only so that people can easily plug in the JDK-supplied PRNG where [math] code expects a RandomGenerator. Phil > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
