Warp wrote:
> 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.

Certainly. You asked what was wrong. It's not a big problem. It's just 
slightly ugly, because you're trying to take a function that currently takes 
one seed-number, and turn it into a function that takes an optional PRNG 
identifier and a variable number of seed numbers. That's hard to do, 
syntactically, without making things ugly (such as by passing a single value 
that's actually a collection of values).

I'm just saying, perhaps having a different function would make it less 
ugly, as well as leaving open the possibility of being able to save and 
recall the PRNG's state. As Mr Berger pointed out, being able to dump out 
the state and reload it would be good too.  Whether you can do the 
dump/reload with the same function that sets the seed is another question, 
tho. I would imagine some PRNGs (RC4 leaps to mind) might take a state that 
needs to be in a specific form.

As an aside, how about allowing a string as a seed, perhaps with hex 
digit-pairs if POV doesn't support 0-255 in strings?

seed(23)
seed("18D8237")

That would seem to allow for the maximum number of bytes in a seed without a 
problem. If you made the state dump/reload also provide/require a similar 
string, you could easily write it to a file, ship it to macros, etc.

-- 
   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

Warp nous illumina en ce 2009-05-19 13:11 -->
>   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.
> 
An option could be to do something similar to the noise generators. You can 
select witch one to use in the global_settings section, with a default one.

It should be possible to add something like:
random_gemerator 2

The generator 1 would be the number 1, the actualy proposed one number 2, and 
there is room to add some other generators.

I also like the idea of been able to use a float as the seed. Providing a float, 
like 1.0 would automaticaly sellect the new generator.

Post a reply to this message

>  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.

IMO, there's no real need for access to larger seeds...
for example mersenne twister (MT19937) is seeded from
a single 32 bit value, even though it generates 624 values for
the internal state. There's more call for access to the RNG
state, but I can't see a way to keep compatability with 3.6 syntax.
So, for now...
RNG_Identifier = seed( Float | Float_Identifier [,Float | Float_Identifier])

I'd like to see a reworking of the syntax for this in 4.0,
in general I think it's bad to have numbered parameters as
was done for media scattering models. I prefer more descriptive
wording. I also think that using optional parameters between ()
as if they were between {} looks ugly.

Ultimately for 4.0 I'd like to see all the command-line, and
ini file options moved into SDL, so that command-line, and
ini file options are always considered to over-ride settings
in SDL. Then separate the scope of such commands into
sections... animiation{}, environment{},scene{},post_process{}.

Seed is probably one of the commands that would belong in
the environment section, along with camera, photons, and radiosity.
It's part of the starting state of the renderer.

RNG_Identifier = random_number_generator {
   [type POV36 | mersenne_twister]
   seed Float | Float_Identifier
};

It's a bit more verbose, but it's more amenable to be
extended in the future.

Post a reply to this message

>  Enhance seed() so that it will take an optional second parameter

I don't think that's a good way to do it. The problem is that the second 
parameter is confusing to people who don't already know the function. Even 
if the parameter is passed as a named constant, like RNG_SUCHANDSUCH (which 
in POV-Ray would probably require #including a file with a name you'll 
forget), this isn't the sort of thing that's useful as a parameter, because 
you're never going to want to change it dynamically. I think it would be 
simpler and clearer to use a separate function for different random number 
generators, like rand_suchandsuch( seed ).

> 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.

I would go with this, because it's easy for the user. In my life, I will 
never see more than 2^32 images, so that many different random number 
streams aren't necessary. The biggest advantages of other RNGs are the 
randomness of their behavior over multiple calls, not the number of 
different streams.

Keep in mind that, in practice, when you are writing a scene and need to 
come up with a seed you just type in a "random" number. If it gives bad 
results, you type in another one. Maybe instead you'll do something that's 
calculated, like frame_number, or the time of day, or something like that, 
but even in these cases, when are you going to run out of values?

At the very least, the simplicity of seed(345) should be available so users 
don't have to learn more than they already do to use a conceptually simple 
feature.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

>  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.

As long as that is the case, I would go with whatever syntax is most useful 
for people who will be generating their scenes programatically, because 
they're the most likely to want to use that feature.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:

> An option could be to do something similar to the noise generators. You can
> select witch one to use in the global_settings section, with a default one.
>
> It should be possible to add something like:
> random_gemerator 2
>
> The generator 1 would be the number 1, the actualy proposed one number 2, and
> there is room to add some other generators.
>

I like this idea as well--very simple. Although, I don't see how the more
complex random generators that Warp has mentioned would be able to be
incorporated in such a scheme, IF we continue to use just seed() with a single
value (as we do now.) I.e., how would seed(23) provide or access all the
multiple variables that have been discussed?

I tend to agree that just about any syntax for more complex seeding(s) would be
OK. Those of us that need a more complex random generator will learn it's
usage; those who just need a 'good' generator will stick with seed(23). I think
it boils down to who needs what: Scientists/cryptographers/experimenters will
likely welcome more complex seed algorithms; the typical POV 'artisan' (like
me) just needs a (better) random-number generator, simply an improvement over
what we have now, with the same easy-to-use syntax.

KW

Post a reply to this message

=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeb### [at] freefr> wrote:
>  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.

Obviously it's not so common in the POV-Ray world :P

Anyway, if there would be intention to implement such a thing in POV-Ray SDL,
there would be no need for a "user-friendly" notation. So e.g. a base64-encoded
string of the raw state data would do as fine as any other notation.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> As an aside, how about allowing a string as a seed, perhaps with hex
> digit-pairs if POV doesn't support 0-255 in strings?

Being on it, methinks the string handling in POV needs reworking anyway... one
more for the POV-Ray "bug"tracker

Post a reply to this message

Jérôme M. Berger wrote:
>     In that case, the seed may take the whole range of values supported
 
> by the algorithm.

In many PRNGs, the seed and the state are distinct structures. Sometimes,
 
for example, the internal state maintains a certain pattern, and the 
algorithm stops working if you put arbitrary data into the state.

-- 
   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

Slime wrote:
> simpler and clearer to use a separate function for different random number 
> generators, like rand_suchandsuch( seed ).

The advantage of changing the seeding rather than the rand() call is there's 
usually a very small number of seed()s, one for each stream.  If you find 
your trees aren't being placed properly, you can change the seed() for the 
tree placement and leave the seed for the leaf placement alone. And you 
don't need to track down every call to rand() and figure out which it is.

Putting it in the defaults is a good idea, but then it prevents using 
multiple different PRNGs in the same scene.

-- 
   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