[Top][All Lists]

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

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

From: Andy Wingo
Subject: Re: Improve `seed->random-state' in stable-2.0?
Date: Mon, 23 Jan 2012 10:52:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Hi Mark,

On Fri 20 Jan 2012 23:45, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> 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


reply via email to

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