On Sat, Jan 9, 2016 at 9:09 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> Hi. > > Relevant excerpt of previous posts: > > [...] >>> >>> 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 >>> >> > (1) > CPUs and OS are nowadays commonly 64-bits based. > Thus one could legitimately wonder whether, on such systems, generating > one "long" value > would not be faster than generating > two "int" values, > especially when 64 bits are necessary in order to produce the next random > "long" or "double" value. > (2) > There indeed exist 64-bits implementations of RNGs: > > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/VERSIONS/C-LANG/mt19937-64.c > http://burtleburtle.net/bob/rand/isaacafa.html > > > I thus propose to create a feature branch that will contain > * a new interface, for when "nextLong()" is the "random bits" producer > You mean another abstract base class. Fine by me. > * the (adapted) "xorshift1024*" RNG implementation from > http://xorshift.di.unimi.it/ +1 to add a new one, assuming someone is willing to do the research and get a clean impl. Looks like the above is GPL, so we have to be careful will adapting code. The benchmarks and discussion there look promising, though. > > * an "adapter" to the existing generic methods > What do you mean by this? * benchmarking code > +1 Phil > > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
