Warp <war### [at] tagpovrayorg> wrote:
>   The current RNG uses a 32-bit seed, so a single parameter to seed() is
> enough to get all possible streams. However, higher-quality random number
> generators usually support much longer seeds, so it would be possible to
> choose among a vastly larger amount of RNG streams. Thus it would be very
> nice if larger seeds could be specified.

Stupid question: Why? What would be the benefit?

Let's have a closer look at the use cases for seeding.

(a) To have multiple independent and uncorrelated RNG streams:

When e.g. randomly placing N trees and M rocks, you may want to use a "fresh"
RNG stream for each of the two tasks, so that in a test render you can place
only the trees, or only the rocks, without this affecting their placement; at
the same time you want the two streams to produce different values, to prevent
apparent correlations between the placement of the trees and rocks.

You can achieve this by using two random streams with different seeds.

To this end, you would probably need just a handful of distinctive seed values -
at most as many as there are RNG streams.

(b) To manually "pick" a certain RNG sequence:

Sometimes you may prefer the results of one random sequence over another; e.g.
you may want to place items at random, and the initially chosen seed may happen
to produce an unfavorable distribution.

You can solve this by trying out different seeds.

To this end, you'll probably try just several handful of different seed values
before you either find a suitable seed, or get tired and figure that the
unfavorable distribution may be virtually uavoidable for statistical reasons.

(c) To automatically "pick" different (but otherwise arbitrary) RNG sequences
based on some other parameter:

For instance, in an animation may want a certain RNG sequence to be different
for frame.

You can achieve this by seeding your RNG with the frame number - or a digest
thereof.

In this case, you'll need as many different seed values as there are frames in
your animation - several thousands probably.


There may be other use cases. However, I guess it will be difficult to find any
that will really require more than a few thousand distinct seed values.

Thus, a single 64-bit floating-point seed value (or even a 32-bit integer) is
probably perfectly sufficient, so that the whole issue boils down to devising a
smart enough way to "inflate" it to a suitable initial state value for the RNG.


If we'd be talking about cryptography, then yes - in that case it would make a
huge difference how many distinct seed values we actually have to choose from;
but even then not because we'd actually use them all, but for the sole reason
that we *could*, so that a bad guy wouldn't know which one we chose.

Other than that, there's no real use in having a high diversity in seeds. So
*that* capability of higher-quality RNGs wouldn't be utilized in POV anyway.

The other major capabilities of higher-quality RNGs - that for practical
purposes the sequences don't repeat, and that they are less prone to produce
obvious patterns - are in no way diminished by reducing the available set of
distinct seed values.

Post a reply to this message