[vox-tech] random number question
Jeff Newmiller
vox-tech@lists.lugod.org
Wed, 15 May 2002 11:49:52 -0700 (PDT)
On Wed, 15 May 2002 msimons@moria.simons-clan.com wrote:
> On Wed, May 15, 2002 at 09:23:07AM -0700, Peter Jay Salzman wrote:
[...]
> > and i assume it's not true across different computers?
>
> False, sequences will be the same across machines with the same CPU (1)
> using the same algorithm.
>
> 1: The main question is that the algorithm be the same, for integer
> based algorithms (which I think rand is) the CPU may not mater at all.
> Just don't count on being able to generate the same sequence between
> a sparc, alpha, and intel line of processor until you test it.
Yes, they are integer algorithms.
C code isn't supposed to depend on cpu-specific issues like overflow and
twos-complement versus ones-complement, so the same code on two different
CPUs ought to act the same in general.
Of course, if the code changes, this may not hold true. For example, if
RAND_MAX changes, the sequence will most likely change. If RAND_MAX is
based on INT_MAX or UINT_MAX, processors with different native word
lengths may indirectly lead to different sequences.
>
> from rand(3) (random(3) has almost the same text)
> # The srand() function sets its argument as the seed for a
> # new sequence of pseudo-random integers to be returned by
> # rand(). These sequences are repeatable by calling srand()
> # with the same seed value.
>
>
> > i'd do the experiment, but i'd rather not reboot my system right now.
> > does anyone know the answer offhand?
>
> The c library rand and random functions produce a sequence of
> pseudo-random numbers based on an initial seed value. This means
> that while the sequence itself is not random (every single time
> the algorithm is started with a seed of X it will spit out certain
> numbers in a certain order).
>
> In practice if you seed the number generator with the current
> time and you do not run your program more than once a second, you
> will get good enough "random" numbers for most purposes.
>
> These algorithms also tend to "cycle" back upon themselves, so
> if they spit out (10, 5, 8, 20, ...) sometime millions of reads
> later the same millions of numbers will be pulled in the same order.
> In one complete cycle the numbers in a sequence should be
> randomly distributed in the range of output numbers... so if the
> outputs are between 0 and 1999 and a cycle takes 2 million reads
> each number should have been hit 1000 times each.
>
> I think each sequence is completely independent of the others...
> in that the order of numbers in one cycle of all sequences will be
> different.
Not quite sure I understand what you are saying here. If you find
yourself at a particular point in the cycle, the numbers that follow are
predetermined. The problem is that the "cycle" for a good pseudo-random
number generator is often much longer than can be represented by the seed
value, so you may not have complete flexibility to choose where in the
cycle you will start. A good seeding algorithm will distribute the
starting points throughout the cycle, so that each seed will appear to
yield a different sequence. A bad one could assign multiple seed values
to the same points in the cycle. :)
> Sometimes is very valuable to be able to have pseudo-random numbers
> which can re-generate a certain sequence of numbers: this is because if
> your program uses "rand" and crashes sometimes, you can set the seed
> value to some constant number that you know leads to a crash then rerun
> a few times with gdb to figure out what is going wrong...
Or so someone else can "reproduce" your results, for closer examination.
[...]
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<jdnewmil@dcn.davis.ca.us> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------