Re: [Bug-apl] Bad quality of the roll function

[Juergen Sauermann]

Hi Blake,

I did in the past. Problem is this:

the normal random allows you to set the seed (srandom()) but not to
retrieve it. However retrieving the seed is necessary to localize ⎕RL.

I then look into the other method of random() to set the seed (initstate()/setstate()).
That looked promising at first (very long random sequences) but using that would require
a larger ⎕RL which would violate the ISO standard.

So the 8-byte integer size of GNU APL limits the random number generator state to 8 bytes
(which is still rather large). I wasn't sure if inistate() exists on all platforms, so to avoid
portability problems i took an 8-byte Lehmer generator instead.

I guess some imprevements are still possible such as fixing the bias (which is acceptable when
your max. random (the right argument of monadic ?) is <= 32 bit bug can get large if not.

Any suggestions are welcome for this topic.

/// Jürgen

On 08/20/2014 06:51 PM, Blake McBride wrote:

Why not use random(3) (or are you)?

Thanks.

Blake

On Wed, Aug 20, 2014 at 9:07 AM, Juergen Sauermann <address@hidden> wrote:

Hi Kacper,

thanks for reporting this. Should be improved in SVN 439.

/// Jürgen

On 08/20/2014 06:47 AM, Kacper Gutowski wrote:

Currently GNU APL uses LCG with modulus 2⋆64 and then reduces values modulo
desired range.  This, beside being slightly biased for ranges not dividing
the modulus, yields reduced periods when range is power of two.

       ?10 16⍴16
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8
11 2 13 12 15 6 1 16 3 10 5 4 7 14 9 8

Doesn't look very random to me.


-k