Re: trouble with rand()??

[Hans-Bernhard B. <br...@ph...>]

On Mon, 5 Jan 2004, Ethan Merritt wrote:

> In article <btbtll$4qp$1...@ne...> you write:
> >
> >> I assume that the original intent (which is not what is stated by
> >> the documentation) was that rand(x) will return a random number
> >> for (x==0), but will reseed with the real part of x if (x!=0).
> >
> >That may not be as simple as it sounds, for the given PRNG function.
> >The internal state of the generator has more significant bits (2 times
> >32 bits) than a double-precision floating point number, unless you
> >were to use its exponent part, too.
> 
> The static constant used in specfun.c consists of a 32 bit int 
> repeated twice to make a 64 bit seed.   If this is acceptable
> for the chosen algorithm, then I figured to do the same
> thing in seeding from the 32-bit init parameter. 

Which parameter?  The actual parameter is a double-precision float. We
have to be careful what the seed argument's scale is supposed to be:
anything smaller than 2**32, using it as a 32-bit int?  Or 0..1 like the
result of rand(), and use it scaled up accordingly?  Come to think of it,
I don't think it's important or even desirable to have rand(seed)  
reproduce the same series of random numbers as one "seed" was taken from.
I think we actually need three variants of calling ranf():

	seed with time()
	seed specified by user
	no seed, just get the next number.

I suggest to map the to rand(negative), rand(positive) and rand(0), in
that order.  Current behaviour would be reproduced by rand(1234567890).

Actually, there are other problems with that generator: it seems to assume
that longs are 32-bit types.  That's not guaranteed by anything, and is
actually becoming less likely every month, given the spread of 64-bit CPUs
these days.

I guess while at it, we should also swallow the constants Xm1 and friends
into ranf() where they belong.  

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.