Hi, > On May 17, 2016, at 12:06 PM, Juergen Sauermann > <juergen.sauerm...@t-online.de> wrote: > > Hi Xiao-Yong, > > the reason is that ⎕RL is defined as a single integer in the ISO standard. > That prevents generators with a too large state.
Okay. I was thinking whether ⎕RL can be an integer vector. Even a combined generator with a 3-int-state would be quite useful for numerical simulations if it could be. > > For somebody seriously into simulations a general purpose generator > will never suffice, but it is fairly easy to program one in APL. We definitely don’t want to make it cryptographically strong, but as a general purpose one, I would hope for decent high quality for relatively long monte carlo simulations. I don’t see an easy implementation because we don’t have exact 64bit unsigned integers and bit operations in APL. If any of you on this list have suggestions in implementing a good RNG in APL, please let me know. > > c++11 is currently not an option because I would like to not reduce the > portability of GNU APL onto different platforms. > > I'll have a look at the % usage. > > /// Jürgen > > > > > On 05/17/2016 06:16 PM, Xiao-Yong Jin wrote: >> Hi, >> >> The LCG used for roll may be fine for some casual uses, but I would really >> like to see a higher quality RNG adopted here. Since speed may not be the >> main concern here, employing the use of c++11 <random> and preferably using >> the std::mt19937_64 seems to be much better for any monte carlo type >> calculations. It could be a trivial change to Quad_RL class, although >> saving the RNG state in a workspace may require a bit more code. What do >> you say? >> >> By the way, since in Workspace::get_RL 'return rand % mod;', you can remove >> the same ‘%’ in all the bif_roll definitions. >> >> Best, >> Xiao-Yong >> >> >> >> >
