Path: utzoo!attcan!utgpu!watmath!watdragon!rose!ccplumb
From: ccplumb@rose.waterloo.edu (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: psuedo-random number generators
Keywords: Random Number Generator
Message-ID: <16697@watdragon.waterloo.edu>
Date: 26 Sep 89 16:31:47 GMT
References: <19504@unix.cis.pitt.edu> <1989Sep13.032352.10321@agate.berkeley.edu> <12003@cit-vax.Caltech.Edu> <1989Sep22.082034.1405@agate.berkeley.edu> <16646@watdragon.waterloo.edu> <1989Sep26.013914.1796@agate.berkeley.edu>
Sender: daemon@watdragon.waterloo.edu
Reply-To: ccplumb@rose.waterloo.edu (Colin Plumb)
Organization: U. of Waterloo, Ontario
Lines: 33

I wrote:

>> No, if you read Knuth, he says using the same generator is better worst-
>> case and at least as good on average.

And Mike Meyer  took me to task.

My memory was slightly faulty.  I was thinking about algorithm B (algorithm M
with X_n = Y_{n+/-1}, I can't be bothered to work out which) and algorithm M
with X_n and Y_n *sucessive* values from the same random-number stream, as
described at the end of section 3.2.2, which references F. Gebhardt [Math. Comp.
21 (1967), 708-709].

Algorithm B Knuth say, "...can be recommended for use in combination with any
other random-number generator."  Start with an array V of size k and a variable
Y set to random values.  Then,

int good_rand()
{
	int j;

	j = Y*k/MAX_RAND;  /* Or Y%k, but the high bits are usually better */
	Y = V[j];
	V[j] = bad_rand();
	return Y;
}

j = bad_rand()%k; also works well, I believe, but Mike is right that I don't
have Knuth backing me up on that.  I wish Knuth wasn't written in such a
ridiculous assembly language.  It would make the algorithms much more
accessible.
-- 
	-Colin