Re: [Chicken-hackers] random numbers for CHICKEN 5

[felix . winkelmann]

> I believe that the scaling done in `C_random_fixnum` is indeed dangerous as it
> may lead to badly-distributed results.
> Using a 64bit PRNG with the "proper" reduction procedure (avoid using the
> modulo, have a look at OpenBSD `arc4random_uniform`) is, IMO, the way to go: 
> you
> can easily reduce a 64bit value to a 32bit one but not the other way around.

I'd like to avoid 64-bit arithmetic on 32 bit systems.
I have changed the scaling now to a loop, which seems to be the proper
way.

> A quick search revealed there's a 64bit version of WELL512a [1] but I can't 
> find
> any other source on this matter.

This version is identical to the 32 bit version, modulo the types. If this is
correct, we can parameterize this, depending on machine word (and
fixnum) size.

>
> If you're not 100% sold on the WELL family I'd suggest to have a look at [2],
> this family of PRNG: they are mind-numbingly simple (have a look at the
> implementation), produces 64bit numbers, is reasonably fast, has a small state
> and is also widely used.

I'm not sold, but I'm kind of tired to look for yet another RNG. Feel free
to replace it, however.

>
> WRT the use of `rand()` to initialize "random_state", I'd use something like
> the good old MT19937 initialization sequence with an unpredictable seed,
> or, if possible, snatch C_RANDOM_STATE_SIZE bytes worth of entropy from the 
> OS.

We should avoid opening /dev/urandom unless explicitly asked for (by using
"random-bytes"). The initialization sequence look interesting, but we would
need an appropriate constant for this PRNG.

> On the topic of seeding set-pseudo-random-seed! nor C_set_random_seed check 
> for
> empty buffers or negative `n` values. Moreover I think that the input should 
> not
> be treated as a circular buffer, you should either give the whole thing or
> nothing.

I have added a check for negative sizes. If the user passes an empty buffer, 
then, fine.. A problem is that the size of the random state is not known to the
user and might change if we decide to replace the PRNG.

>
> Onto the use of getrandom() now! You have to take into account that there are
> two different places you have to look at: the kernel, where the getrandom()
> syscall is implemented, and glibc, where the getrandom() procedure is defined.
> Right now the check is bogus because it checks for the syscall to be defined 
> and
> uses the glibc function (which is defined in /usr/include/linux/random.h),
> implementing a tiny `syscall()` wrapper lets users with a old glibc to use 
> this
> mechanism.

Done.


felix