Re: random number trap [message #4971] |
Mon, 04 September 1995 00:00 |
sterner
Messages: 106 Registered: February 1991
|
Senior Member |
|
|
In article <DE33pI.G1D@hpl.hp.com>, peter@hpl.hp.com (Peter Webb) writes:
> So if you repeatedly call a procedure that
> calls randomu, the return will be the same if the calls occur within a
> second of each other, but will be different if they are in different
> seconds.
>
Maybe this has been answered already since I haven't been following
this newsgroup for a few days.
The way I solve this is to include a common unique to the routine
needing random numbers and store the random number seed in that
common. This is only needed if the routine is called multiple
times with more than one call per second. If you generate all the
needed random numbers in the same call this problem does not occur
(as you stated above).
Ray Sterner sterner@tesla.jhuapl.edu
The Johns Hopkins University North latitude 39.16 degrees.
Applied Physics Laboratory West longitude 76.90 degrees.
Laurel, MD 20723-6099
WWW Home page: ftp://fermi.jhuapl.edu/www/s1r/people/res/res.html
|
|
|
Re: random number trap [message #4983 is a reply to message #4971] |
Wed, 30 August 1995 00:00  |
rolf
Messages: 2 Registered: August 1995
|
Junior Member |
|
|
In article <DE33pI.G1D@hpl.hp.com>, peter@hpl.hp.com (Peter Webb) writes:
> So if you repeatedly call a procedure that
> calls randomu, the return will be the same if the calls occur within a
> second of each other, but will be different if they are in different
> seconds.
>
According to all I know about pseudo (!) random number generators,
it is crucial that the updated seed is passed on to the next call.
Even if your system clock was updated on a nanosecond basis you
would get nothing like random behaviour, but something very strictly
correlated with the execution time of your program. If interested,
read something about the theory of RNG, e.g. Numerical recipes.
Rolf
+----------------------------------------------------------- ----------------+
| Rolf P. W"urtz | mailto:rolf@cs.rug.nl | URL: http://www.cs.rug.nl/~rolf/ |
| Department of Computing Science, University of Groningen, The Netherlands |
+----------------------------------------------------------- ----------------+
|
|
|
Re: random number trap [message #4985 is a reply to message #4983] |
Tue, 29 August 1995 00:00  |
scott
Messages: 17 Registered: January 1994
|
Junior Member |
|
|
Peter Webb writes
> A warning about the random number generator in IDL/PV-Wave (not a bug,
> per se, but something to watch out for).
>
> As the documentation states, if the seed value given to randomu is
> undefined, it is derived from the system time. The time only changes
> once per second, however. So if you repeatedly call a procedure that
> calls randomu, the return will be the same if the calls occur within a
> second of each other, but will be different if they are in different
> seconds.
>
> This can lead to random numbers being a *lot* more structured than you
> expect. I had naively expected that the seed value would change each
> microsecond, so this behavior came as a bit of a surprise.
>
> The solution is to place the seed variable in a common block so that it
> is preserved from call to call, and then each returned sequence will
> truly be random.
>
> Peter
>
> --------------------------------
> Peter Webb, HP Labs Medical Dept
> E-Mail: peter_webb@hpl.hp.com
> Phone: (415) 813-3756
Actually, the problem goes much deeper than the granularity of the system
time, and hinges on what you mean by "random." Many scientific users
expect a "random" variable to have a Gaussian distribution, which no
"random number generator" in any language is likely to provide.
For an excellent discussion of this problem, as well as nice, simple
solutions, see W. H. Press et al., 1992: Numerical Recipes, Cambridge
University Press, Chapter 7 (Random Numbers).
--
A. Scott Denning scott@abyss.Atmos.ColoState.edu
Dept. of Atmospheric Science Phone (970)491-2134
Colorado State University Fax1 (970)491-8428
Fort Collins, CO 80523-1371 Fax2 (970)491-8449
|
|
|