Re: [Bug-apl] RNG

[Juergen Sauermann]

Hi Xiao-Yong,

I have fixed the redundant %, see SVN 728.

Regarding length, the GNU APL generator is 64-bit long (and so are
GNU APL integers), which should suffice for most purposes.

Regarding bit vectors in APL, most people use integer 0/1 vectors
for that (and then you have all boolean functions available) and
2⊥ resp. 2 2 2 ... 2⊤ for conversions between 0/1 vectors and integers

You can also call into C/C++ libraries from GNU APL using native functions.

/// Jürgen

On 05/17/2016 07:44 PM, Xiao-Yong Jin wrote:

Hi,

On May 17, 2016, at 12:06 PM, Juergen Sauermann <address@hidden> 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