l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2002 May 15 12:42

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] random number question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] random number question



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
---------------------------------------------------------------------------

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.