"John C. Hayward" writes:
> On Wed, 30 Apr 1997, Perry E. Metzger wrote:
> > >      The random() function uses a non-linear additive feedback
> > >      random number generator employing a default table of size
> > >      31 long integers to return successive pseudo-random numbers
> > >      in the range from 0 to (2**31)-1.  The period of this
> > >      random number generator is very large, approximately
> > >      16*((2**31)-1).
> > > ===
> > > This should be large enough for _any_ application.
> I should have said for the 256 long integer which has a period of > 2^69.
> > 
> > Not for cryptography. Not by a long shot.
> > 
> > Also, that random number generator pretty much sucks for many classes
> > of monte carlo simulations.

> If you compute at the rate of 1 billion events per second (~2^30) for
> a year (~2^25 seconds) it would take 2^14 years to cycle for the 256 long
> integer state.

Sorry, but you've touched my hot buttons. Prepare to be flamed.

1) Cryptographic applications don't care a flying rats ass for big
   numbers. The newbies always think huge numbers are impressive. A
   monoalphabetic substitution over 8 bit ASCII has, in theory, 256!
   keys (a giant number!) but can be cracked in milliseconds by a
   computer program with its arms tied behind its back, and in minutes
   by a smart eight year old child.

   A linear congruential generator can be predicted after only a
   couple of output numbers. The problem of cracking an LC PRNG
   sequence is so easy it is often given as a first week assignment to
   students in crypto classes.

2) Similarly, for monte carlo stuff, the fact that the numbers have
   long period isn't nearly as interesting as the fact that they don't
   have statistical properties appropriate for many kinds of
   simulations. Again, if you are trying to do these sorts of
   simulations, you don't give a pair of fettid dingo's kidneys that
   the period is 2^69 -- you care that the numbers aren't good enough
   to make your simulation results work out.

Perry