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

Alain <ele### [at] netscapenet> wrote:
> 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.

Unfortunately, that's a no-go: POV-Ray's parser framework isn't designed to tell
the difference between 1 and 1.0.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> 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.

Not if it's used in some huge macro. In that case, it's part of the starting
state of the macro.


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

I'd actually favor something like:

My_Random_Stream = Pov36_Rng(4711);
My_Random_Number = My_Random_Stream.getNext();

Other_Random_Stream = Mersenne_Twister_Rng(...);
Other_Random_Number = Other_Random_Stream.getNext();

i.e. sort of defining the different RNGs as different, independent objects
(which just "happen" to use the same method identifier to get the next value).

But that's "future music" as we'd say in German.

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.4a141b4b38187d7ef708085d0@news.povray.org...
> "Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
>> 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.
>
> Not if it's used in some huge macro. In that case, it's part of the 
> starting
> state of the macro.

Sure, but a normal macro that isn't redefined multiple times
would belong in the environment section too... any subroutine
that can be compiled once would go there. With some
4.0 macro syntax to make it clear that is what is going on hopefully.

>> 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.
>
> I'd actually favor something like:
>
> My_Random_Stream = Pov36_Rng(4711);
> My_Random_Number = My_Random_Stream.getNext();
>
> Other_Random_Stream = Mersenne_Twister_Rng(...);
> Other_Random_Number = Other_Random_Stream.getNext();
>
> i.e. sort of defining the different RNGs as different, independent objects
> (which just "happen" to use the same method identifier to get the next 
> value).
>
> But that's "future music" as we'd say in German.

That would be hard on the parser, every RNG command would be
at the top level, if they're inside a common constructor then at the top
level there's just the check for the constructor.

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?

  You could only specify integer literals like that. You couldn't do
something like this, which isn't even rare:

#declare S = seed(1234 + frame_number);

with a long seed.

-- 
                                                          - Warp

Post a reply to this message

StephenS <nomail@nomail> wrote:
> #declare S4 = seed (1234, 2, array[4] { 1, 2, 3, 4 } )

  If the extra seed values are given as additional parameters, there's no
need for an array, as they could be given as direct parameters, ie:

#declare S4 = seed (1234, 2, 1, 2, 3, 4 );

  That could work, although it's still a small cosmetic problem that the
seed is specified as the 1st, 3rd, 4th, etc. parameters, so there's an odd
discontinuity there...

-- 
                                                          - Warp

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> 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?

  seed() can be changed so that it can take any amount of parameters.

  If the current RNG is being used, it would just take the first parameter
and ignore the rest. If RNGs with support for larger seeds are used, they
would take as many parameters as given (up to the maximum amount supported
by the RNG).

-- 
                                                          - Warp

Post a reply to this message