Re: Improve `seed->random-state' in stable-2.0?

[Andy Wingo <wingo@pobox.com>]

Hi Mark,

On Fri 20 Jan 2012 23:45, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> How about, we extend seed->random-state to operate on bytevectors, and
>> have that interface do the right thing.
>
> I agree that it would be nice for `seed->random-state' to support
> bytevectors as well, but for many (most?) purposes that would be a very
> awkward interface to use.

Really?  My thought would be that if I have to initialize a PRNG, I need
some random bits.  Dunno.  Deprecating the number interface does have
the advantage that we can perhaps move people to use your nice new
functions, instead of initializing with (getpid) or whatever it is that
they are using.

> Even if we keep a broken `seed->random-state', there's another problem:
> our PRNG sucks rocks.  If we constrain ourselves to produce the same
> sequence of random numbers for a given seed, that means that we're stuck
> with this very weak PRNG for the entire 2.0 series.
>
> Can't we just make a clean break now?  2.0 is still not widely deployed,
> so now is a great time to assert our right to change the PRNG at will.
> As you say, it's unlikely that anyone is relying on this anyway.
> If anyone is, wouldn't it be better to deal with that now?

While I agree about the badness of the PRNG -- though we shouldn't
overstate that; for being so simple, MWC does well -- but I really don't
think that we should change the default behavior now.

OTOH, we can make seed->random-state on bytevectors return an rstate
with a different implementation of scm_t_rng -- for example, we could
use GMP's mersenne twister API.

In any case, don't let stability concerns stop you from hacking on a
fix!  We'll probably get the first 2.2 preview out within a a year, and
we certainly need to change the default behavior for then

Andy
-- 
http://wingolog.org/