Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!gatech!hao!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Random Numbers ...
Message-ID: <7364@brl-smoke.ARPA>
Date: 28 Feb 88 01:11:20 GMT
References: <11972@brl-adm.ARPA> <7097@sol.ARPA> <3472@bobkat.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <3472@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes:
>Linear congruential random number generators are fine because of their
>simplicity, but unless the entire seed is used the results are not very
>random.  Get ahold of a graphics system and do a simple pairs test by
>plotting random x-y positions for a while.  You'll see nifty patterns.

There are patterns in the sequences produced by any deterministic
generator, although you may not be able to see them via simple plotting.
This is what makes cryptanalysis of machine ciphers feasible.

>The BSD (?) random() functions are decidedly superior, though somewhat
>slower.

Those use a linear-feedback shift-register method (if used in a mode
where the state information is greater than 32 bits).  Golomb wrote a
whole book about the algebra and statistics of such sequences.  LFSR
sequences can act as if they are "more random" than LC sequences for
naive use, but it does depend on what you use them for.

UNIX System V provides 48-bit LC sequence generators under names such
as irand48(), drand48(), etc.  Because these use more bits than the
example code I posted, they are generally better.  It is too bad that
there doesn't seem to be a single, FAST, statistically dominant method
that could be provided for all applications.  Programmers keep having
to provide their own RNGs to have sufficient confidence in their
suitability for specific applications.