On 12/26/15 4:52 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. > > 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?
Why? We don't have contributions of other RNGs implemented using 64-bit blocks of data. In theory, I guess you could do that, but I don't know of any and all the ones we have use 32-bit words. Phil > > 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 > > > --------------------------------------------------------------------- > 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
