"gregjohn" <pte### [at] yahoocom> wrote:
> The neatly ordered, predictable pattern of red dots in the top half of the image
> are generated with povray's rand() function.  They demonstrate what you get if
> you cause a monotonic increase in the seed value.  Once I had a project
> "ruined" by this predictable pattern because I was exploring some parameter
> space via use of the #declare RSEED=seed(frame_number).

I became aware of these issues as a co-op student when running some Monte Carlo
simulations for a U.S. Air Force contractor.  Not that I know anything about
it; I was working with a professional mathematician.

If you think POV's rand() is bad, take a look at the IBM 360's RANDU() function.
The parameters for this LCG were chosen with hardware optimization in mind. It
seems that no thought was given to the quality of the number stream; perhaps
the implementer was unaware of the mathematical issues.

A whole bunch of scientific studies from the early '70s were invalidated when
this bug was discovered.

What's more, quick look through Google showed that RANDU() was far from the
worst LCG out there.

LCGs are simple and fast, and that's probably why every built-in pseudorandom
number generator that I've seen is an LCG.  A high quality LCG is fine for
casual works, but if you're doing serious statistical or scientific work, you
best study up on non-LCG pseudorandom number generators and write your own.

I've attached some frames of a RANDU() animation.  (I'm not very good at
compression, so I can't post it to p.b.a.)  A simlar run of POV's rand() showed
no discernable visual pattern, but a pattern is in there, even with a stream
from a single seed() call.  (It was a suspicious regularity in some of my POV
runs that prompted me to do the test.)  All that means is that POV uses better
LCG parameters than IBM did.

Post a reply to this message

Attachments:
Download 'randu.jpg' (399 KB)

Preview of image 'randu.jpg'