[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/38883: Replace the algorithm used by random (3) by the Mersenne Twister (mertwist.c)
The following reply was made to PR lib/38883; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
To: Alan Barrett <apb%cequrux.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: lib/38883: Replace the algorithm used by random (3) by the
Mersenne Twister (mertwist.c)
Date: Sun, 31 Aug 2008 19:00:51 +0000
On Mon, Aug 25, 2008 at 12:22:56PM +0200, Alan Barrett wrote:
> On Mon, 25 Aug 2008, David Holland wrote:
> > > Thus, why not implement it as the standard algorithm for random (3)
> > > group of calls?
> > We can't (or at least shouldn't) do this because it would break the
> > initstate() and setstate() interface to random(3).
> Do people really expect the kind of repatability offered by the
> initstate/getstate interface to persist across operating system
> upgrades? In other words, do we guarantee that values returned by
> initstate befoer an upgrade may be passed to setstate after an upgrade?
I'm not sure. I once came very close to writing code that did, but
that was a long time ago and used getstate() as well as setstate(),
which we don't seem to support.
> Even if we do need to retain this level of compatibility, there seem
> to be enough unused values in the first (int) of the state array that
> we could encode which algorithm is used. Old algorithms would still
> have to work as if the old value of MAX_TYPES were retained, but it's
> nevertheless possible to add new algotithms.
That sounds promising though, provided that it's actually worth
deploying another algorithm.
David A. Holland
Main Index |
Thread Index |