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

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

Good point. Probably still the easiest format if you want to dump internal 
state and then reload it later.

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

Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> IMO, there's no real need for access to larger seeds...

  There are RNGs and applications for them where larger seeds are needed.

  Someone mentioned encryption, where the seed acts as the encryption key.
Sure, you could always argue "nobody will ever need encryption in POV-Ray".
You could make the same argument about half of POV-Ray's features.

  I'm pretty sure there are things like stochastic simulations where seeds
larger than 2^32 could be useful.

  As I mentioned in another post, it makes little sense to me to stop the
user from accessing the features of the RNG simply because someone can't
think of good uses for them. And I really think that going the old route
of "2^32 random number streams ought to be enough for anybody" is not smart
in the long run.

> for example mersenne twister (MT19937) is seeded from
> a single 32 bit value

  If that's true, then IMO that lessens the usefulness of MT.

  The RNG I'm considering supports very large seeds (up to something like
8192-bit seeds if so configured) and has very high quality and speed.

-- 
                                                          - Warp

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:
> > 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.

  I'm not sure if you got the idea, but the addition of new RNGs with
larger seeds would *not* change the current usage of RNGs in any way.
You could still use the current RNG in the *exact* same way as currently.

  If you don't care about which RNG is used or how large the seeds are,
then you can simply ignore the extra stuff and use seed() and rand()
exactly like now.

  I really don't see how limiting the seeding is "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.

  How many of the features supported by POV-Ray have you ever used in your
life? Would you like those features you haven't used to be removed because
you have never used them?

  Does it bother you that POV-Ray supports more features than what you use?
If not, then why would it bother you if POV-Ray supported long seeds,
especially if you don't even have to know how they are specified and you
can still use seed() and rand() like currently?

  Can you agree that *some* people might find useful uses for longer seeds
even if you don't, exactly in the same way as some people find useful uses
for other POV-Ray features that you have never used?

-- 
                                                          - Warp

Post a reply to this message

>  If you don't care about which RNG is used or how large the seeds are,
> then you can simply ignore the extra stuff and use seed() and rand()
> exactly like now.
>
>  I really don't see how limiting the seeding is "easy for the user".


That's fine then. It's just the simple syntax which is easy.

>  Can you agree that *some* people might find useful uses for longer seeds
> even if you don't, exactly in the same way as some people find useful uses
> for other POV-Ray features that you have never used?

I can agree that they might. However, I can't imagine a situation where it 
would be useful, so the point to consider is whether it's worth the time to 
implement the feature (and fix any bugs it may have afterwards). At least we 
should come up with an imaginary case where someone might benefit from this 
functionality.

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

Post a reply to this message