bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] RNG


From: Xiao-Yong Jin
Subject: Re: [Bug-apl] RNG
Date: Tue, 17 May 2016 12:44:10 -0500

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
>> 
>> 
>> 
>> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]