I have discussed with the team about the idea of adding alternative,
higher-quality random number generators to POV-Ray 3.7. The current generator
would be kept for backwards compatibility, but alternatives would be offered.

  The only thing which is a bit open is the exact syntax for this. So far
this is the best idea:

  Enhance seed() so that it will take an optional second parameter, which
would specify the RNG algorithm used. It would default to the current RNG.
The rand() function would remain unchanged (internally it smartly selects
the proper RNG from the type of seed given to it). In other words, you would
be able to do, for example, like this:

#declare S1 = seed(1234); // Use the current RNG
#declare S2 = seed(1234, 1); // Identical to the above.
#declare S3 = seed(1234, 2); // Use second RNG algorithm.

  Additional algorithms might be added in the future. As mentioned, rand()
would be unchanged, so its usage would be the same:

#declare RandomValue1 = rand(S1);
#declare RandomValue2 = rand(S3);

  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.

  The problem here is one of syntax. How to do this? Here are the ideas
so far:

1) Simply don't support seeds larger than 32-bit. This would work, but would
   be a bit of a bummer because the capabilities of higher-quality RNGs
   wouldn't be fully utilized.

   Alternatively, since seed() actually takes a (64-bit) float rather than
   a 32-bit integer, the seed range could be somewhat enlarged by taking
   the entire float range into account. This would allow using seeds of
   about 52 bits. (But it's still a long shot from the thousands of bits
   supported by higher-quality RNGs.)

2) Make it possible to give either a regular float (as now), or an array
   of floats as the first parameter of seed(). This way larger seeds can
   be specified as an array.

   While a bit cumbersome, it's not as bad as it may sound at first, because
   it's possible to do eg. this:

     #declare S = seed(array[4] { 1, 2, 3, 4 }, 2);

   It would still be nicer if something less cumbersome could be used,
   though...

3) Use an alternative function for long seeds. For example:

     #declare S = longseed(2, 1, 2, 3, 4);

   (where the first parameter specifies the RNG type used.)

   One small cosmetic problem with this is, however, that it's a bit
   inconsistent with the seed() function. seed() takes the RNG type as
   the second parameter, while longseed() would take it as the first
   parameter. This can be a bit confusing.

4) Create an entirely new syntax for specifying a group of values. This,
   however, would be laborious and should preferably be avoided.


  Opinions and additional ideas will be appreciated.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> I have discussed with the team about the idea of adding alternative,
> higher-quality random number generators to POV-Ray 3.7. The current generator
> would be kept for backwards compatibility, but alternatives would be offered.
>
>   The only thing which is a bit open is the exact syntax for this. So far
> this is the best idea:
>
>   Enhance seed() so that it will take an optional second parameter, which
> would specify the RNG algorithm used. It would default to the current RNG.
> The rand() function would remain unchanged (internally it smartly selects
> the proper RNG from the type of seed given to it). In other words, you would
> be able to do, for example, like this:
>
> #declare S1 = seed(1234); // Use the current RNG
> #declare S2 = seed(1234, 1); // Identical to the above.
> #declare S3 = seed(1234, 2); // Use second RNG algorithm.
>
>   Additional algorithms might be added in the future. As mentioned, rand()
> would be unchanged, so its usage would be the same:
>
> #declare RandomValue1 = rand(S1);
> #declare RandomValue2 = rand(S3);
>
>   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.
>
>   The problem here is one of syntax. How to do this? Here are the ideas
> so far:
>
> 1) Simply don't support seeds larger than 32-bit. This would work, but would
>    be a bit of a bummer because the capabilities of higher-quality RNGs
>    wouldn't be fully utilized.
>
>    Alternatively, since seed() actually takes a (64-bit) float rather than
>    a 32-bit integer, the seed range could be somewhat enlarged by taking
>    the entire float range into account. This would allow using seeds of
>    about 52 bits. (But it's still a long shot from the thousands of bits
>    supported by higher-quality RNGs.)
>
> 2) Make it possible to give either a regular float (as now), or an array
>    of floats as the first parameter of seed(). This way larger seeds can
>    be specified as an array.
>
>    While a bit cumbersome, it's not as bad as it may sound at first, because
>    it's possible to do eg. this:
>
>      #declare S = seed(array[4] { 1, 2, 3, 4 }, 2);
>
>    It would still be nicer if something less cumbersome could be used,
>    though...
>
> 3) Use an alternative function for long seeds. For example:
>
>      #declare S = longseed(2, 1, 2, 3, 4);
>
>    (where the first parameter specifies the RNG type used.)
>
>    One small cosmetic problem with this is, however, that it's a bit
>    inconsistent with the seed() function. seed() takes the RNG type as
>    the second parameter, while longseed() would take it as the first
>    parameter. This can be a bit confusing.
>
> 4) Create an entirely new syntax for specifying a group of values. This,
>    however, would be laborious and should preferably be avoided.
>
>
>   Opinions and additional ideas will be appreciated.
>
> --
>                                                           - Warp

Offhand, if the length of the array of floats that the higher quality RNG
requires is less than or equal to 5, could the existing vector syntax be used?
Of course, feeding a vector to the seed() function would implicitly select the
better RNG:
#declare S1 = seed(1234);         // Use the current RNG
#declare S2 = seed(1234, 1);      // Identical to the above.
#declare S3 = seed(<1,2,3,4>, 2); // Use second RNG algorithm.
#declare S4 = seed(<1,2,3,4>);    // short hand for second RNG algorithm,
                                  //  same as above

Or something.

-Reactor

Post a reply to this message

Reactor <rea### [at] hotmailcom> wrote:
> Offhand, if the length of the array of floats that the higher quality RNG
> requires is less than or equal to 5

  It's not that the RNG *requires* longer seeds. It *supports* longer seeds.

> could the existing vector syntax be used?

  It could be one idea, although a bit limited.

> Of course, feeding a vector to the seed() function would implicitly select the
> better RNG

  I think it's better for the syntax to be the same and consistent for all
RNG types. Besides, if there were more than one RNG type supporting longer
seeds, which one would be chosen?

-- 
                                                          - Warp

Post a reply to this message

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

clipka <nomail@nomail> wrote:
> Other than that, there's no real use in having a high diversity in seeds.

  I don't agree with the idea that since you can't think of any use of
large seeds, we should not offer them for the user if he wants to use
them, given that the RNGs support them and it's only a question of what
would be the handiest SDL syntax to interface with them.

  Let me as you the reverse question: Why should we *not* offer large
seeds? Why limit the usability of the RNGs for no good reason?

  This is not a question of it being *difficult* to implement. It's just
a question of *choosing* which SDL syntax would be the most fluent to
interface with it. I see absolutely no rational reason to limit the
usability of higher-quality RNGs simply because it's a bit difficult to
choose the SDL syntax.

-- 
                                                          - Warp

Post a reply to this message

clipka wrote:
> 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 num
ber
>> 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 v
ery
>> 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.
> 
> ...

	There is a very common use case that you have forgotten: to be able 
to save the state of the random generator so that you can pick up 
from the same point later (in a subsequent animation frame for 
example). This requires two things:
- A function that returns the current state of the generator;
- The ability to initialize the generator with this state.

	In that case, the seed may take the whole range of values supported 
by the algorithm.

		Jerome
-- 
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Warp wrote:
>   Let me as you the reverse question: Why should we *not* offer large
> seeds? Why limit the usability of the RNGs for no good reason?

It disturbs the syntax of the seed() call that exists even more. So it's 
mostly a matter that you already addressed: the syntax is ugly.

However, consider your longseed() example. Why not pass the random number 
stream to the longseed() routine.  seed() would still be used to seed and 
create a random number generator, but now you can reseed the generator with 
longseed().  Given that someone might want to do this with the current PRNG, 
it could just be called "reseed()".

Conflating "create a PRNG stream" with "set the seed" seems to be at the 
crux of the syntactic-ugliness problem.  Just a thought to stew upon.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Let me as you the reverse question: Why should we *not* offer large
> > seeds? Why limit the usability of the RNGs for no good reason?

> It disturbs the syntax of the seed() call that exists even more. So it's 
> mostly a matter that you already addressed: the syntax is ugly.

  But it's not like you would notice if you don't care about the extra
long seeds. If you are content with the 32-bit seeds, you can use seed()
in the exact same way as now. The long seeds would just be an extra which
doesn't disturb the currently existing syntax.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
....
> #declare S1 = seed(1234); // Use the current RNG
> #declare S2 = seed(1234, 1); // Identical to the above.
> #declare S3 = seed(1234, 2); // Use second RNG algorithm.
....
From an end user point of view, this is good. Can it be optionaly expanded
again?
#declare S4 = seed (1234, 2, array[4] { 1, 2, 3, 4 } )
to cover any additional requirements.

Stephen S

Post a reply to this message

Sounds like an excellent way of making povray more powerful without breaking the
old syntax.

I also think your philosophy is purely correct about erring on the side of
giving it more power. Giving povray a military-grade RNG may prevent some jerk,
five years from now, from complaining that it doesn't have such a quality RNG.

I sometimes wonder if there were a debate about giving us powerful tools like
the trace() function.  I could imagine someone saying, "povray is a raytracer,
not a modeler", so why would you give it functions that are properly handled in
the modeling software?

Post a reply to this message