Hi David,

You wrote to Mike Kerna:

DN>MK>This is the best way I have found for generating random numbers, and to
DN>MK>many decimal places:

DN>It isn't "the best" way I have found.

Seconded!

DN>MK>The actual formula is  x = ( rand() - minRand ) / ( maxRand + 1.0 -
DN>MK>minRand )

DN>MK>which ends up being:

DN>MK>x = ( rand() - 0.0 ) / ( 32767.0 + 1.0 - 0.0 );

DN>This will only give you 15-bit random numbers. You need to use a better base
DN>PRNG to get decent floating point PRN's. The generator I posted a couple of
DN>weeks ago does 32-bit PRN's, including floating point. Since this exceeds
DN>the size of a 'float' mantissa, it was typed as 'double'.

Then there are the ones in SNIPPETS...

DN>MK>Of course, you can combine expressions.

DN>If you make subsequent calls to rand() to build a single floating point PRN
DN>then this can introduce autocorrelations into the sequence.

Even if it doesn't it reduces the length of the sequence available.

DN>MK>I have generated huge lists of
DN>MK>numbers that don't repeat, although you can seed the generator with the
DN>MK>clock time and date.  I also plotted the numbers generated in a stats
DN>MK>program and found them to be uniformly distributed.

DN>What goodness-of-fit test did you use?

DN>The Chi-squared is the most popular, but is only good with large sample size
DN>for discrete distributions, such as the Discrete Uniform DU(0..32767).

DN>A more interesting approach is to use the floating point PRNG and check its
DN>goodness-of-fit with the continuous uniform distribution U(0,1). This is the
DN>more common benchmark of uniformity in PRNG's.

DN>Moreover, good PRNG's are supposed to produce stochastically independent
DN>PRN's, so no autocorrelations should appear in the sequence, at least in
DN>shorter runs. This is impossible to achieve in the long run, as the sequence
DN>recurs completely with the periodicity of the PRNG. In the case of rand()
DN>from the C library, the period is 32,768 numbers. For the code I posted the
DN>period is 4,294,967,296 numbers.

Bit short that :-) Fortunately is isn't always true, it depends on the
algorithm used by the random number generator, certainly the Borland one
used in BC 3.1 has a much longer period. In the comments they claim 2^32
(quite possible looking at the code), the same as yours.

RAND1 from snippets claims a period of 2^122...

DN>Anyhow, give my code a run through your tests and see how it measures up. I
DN>don't think you'll be disappointed.

Me neither, It'll be better than the compiler one anyway...

George

 * SLMR 2.1a * Computers eliminate spare time.

--- Maximus/2 3.01