Re: [Sbcl-devel] More randomness

[Nikodemus S. <nik...@ra...>]

2009/11/14 Faré <fa...@gm...>:

> Is there anything obviously wrong with it? Would it be OK to merge
> that into the official SBCL? I'm willing to work on it until it's in a

I commented on this on #lisp -- just wanted to repeat some the same
things here so that people can better disagree if I have badwrong
ideas.

0. I think accepting numbers and arrays as seeds is a good idea. I'm
side-stepping the issue of whether reading from /dev/urandom like this
is OK. I don't know -- but even if that part is omitted, users needing
that can still do it and use it to initialize random-state via the new
array-seed interface.

1. Comments. The array-mangling code needs to be commented: What does
it do, and how do we know it does it properly? Is this a know
algorithm, or something cooked up for the purpose?

2. Documentation. The extended public API should be documented in the
MAKE-RANDOM-STATE docstring (or if there is a new public function,
there.)

Semi-unrelated things that I wonder about -- but which I don't think
are make-or-break issues for this patch:

* Should we expose the state vector to the user (even as a copy?): it
would make saving random-states somewhat easier, I guess.

* Should we document the "optimal" seed array-element-type and length?

* Should we implement eg. Yarrow (cryptographically secure PRNG) for
use-cases like yours -- and make it selectable using
*RANDOM-STATE-ALGORITHM* or something? Or just as a contrib?

Cheers,

 -- Nikodemus