help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bad random numbers


From: Mike Miller
Subject: Re: bad random numbers
Date: Tue, 13 Jul 1999 16:40:19 -0500 (CDT)

John--

The results you produced show the same problem and it *is* a serious
problem.  Just look at what you produced here:

> Here is a sequence of runs on my system:
> 
>   bash:127> echo "rand (3)" | octave -qf
>   ans =
> 
>     0.35202  0.32636  0.76954
>     0.78519  0.16961  0.68034
>     0.15899  0.68584  0.50857
> 
>   bash:128> echo "rand (3)" | octave -qf
>   ans =
> 
>     0.509432  0.071253  0.262760
>     0.425929  0.909894  0.729762
>     0.722494  0.235420  0.788238
> 
>   bash:129> echo "rand (3)" | octave -qf
>   ans =
> 
>     0.666845  0.816146  0.755982
>     0.066669  0.650177  0.779184
>     0.285993  0.785003  0.067902
> 
>   bash:130> echo "rand (3)" | octave -qf
>   ans =
> 
>     0.82426  0.56104  0.24920
>     0.70741  0.39046  0.82861
>     0.84949  0.33459  0.34757


Note that the numbers in the 1,1 cell of the matrices follow a pattern
(increasing by .157 with each replication).  There should be no pattern.
The numbers should be independently distributed.  Independence is an
absolute necessity.

Using the same code:  echo "rand (3)" | octave -qf
If I enter this command twice in rapid succession, the same 3x3 matrix is
produced both times.  That is not good when we are trying to do a
simulation study.

Did you see Jim Van Zandt's posting?  He ran a script that bangs out many
replications in rapid succession and it was clear that the random numbers
were following the clock somehow.

I don't understand how you're coding this.  The initial seed should come
from the clock, and it should use all the digits, especially down in the
millisecond range.  The relation of the seed to the first random number
produced should be highly nonlinear (random looking).  There should be no
increasing pattern with time.



> You are looking at a really small sample of numbers returned from the
> the generator.  If you ask for a larger sample, I think you will find
> that they are normally distributed.

They are uniformly distributed, I'm sure, but that isn't the problem.  The
problem is that they are not independent.  The sample size is not relevant
because the problematic dependency is highly replicable.



> The number of digits displayed is due to the way that Octave tries to
> display numbers without dropping precision.  For example, try
> 
>   x = [0.123456789; 1.23456789];
>   for y = 10.^(-4:4); x/y, end

I see -- it's retaining at least 5 significant digits for every number and
displaying all numbers in the same format.  Thanks for the clarification.

Regards,

Mike

-- 
Michael B. Miller
University of Missouri--Columbia
http://taxa.psyc.missouri.edu/~mbmiller/



---------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.  To ensure
that development continues, see www.che.wisc.edu/octave/giftform.html
Instructions for unsubscribing: www.che.wisc.edu/octave/archive.html
---------------------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]