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

Warp <war### [at] tagpovrayorg> wrote:
> Slime <fak### [at] emailaddress> wrote:

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

Good argument, I have to say. (I'll probably never get around to using all the
features POV offers, unless I were to spend full-time with it--which isn't so
different than I what I do now!)

KW

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> > 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

Actually, most common *implementations* of the Mersenne Twister use a single
32-bit value to seed the generator. In actuality, the "seed" of the Mersenne
Twister can be any 2^19937 bit value, except all 1 bits. In practice, we use a
single 32-bit value to "randomly" generate the seed, where the "random" part is
usually an LCG. Some specific implementations do allow seeding the with the full
range of valid seeds. The method of seeding is a separate issue from whether the
MT is a good RNG.

In practice, you're going to want a simple seeding system that uses a single
32-bit value, for people who just need data that "looks" as random as possible.
Then you will want a full-range seeding system (such that it places the RNG
anywhere in its period), for people who need data that IS as random as
possible.

For raytracing, I'll venture a guess that 99.9% or more of our users just need
data that LOOKS as random as possible. Very few people need data that truly IS
as random as possible. The distinction is subtle.

Consider shuffling a deck of cards. Each time we shuffle the deck, use a truly
random process to determine the shuffling, like thermal noise or radioactive
decay or whatever. This is basically what happens when you seed a high quality
RNG. Regardless of how you seed the RNG, as long as the seed is essentially
random, the output will be completely random for most practical purposes.

So, back to the card shuffling example: Do this 16 times, to get 2^4 (most
likely) different shufflings of the deck. (I'm using 2^4 to help exaggerate the
problem of insufficient seed space.)

Now consider each of these 16 shufflings as corresponding with a particular
"seed" in the range 0 to (2^4)-1. Each of these 2^4 shuffled decks appears
completely random, because they ARE completely random (remember, the thermal
noise or whatever?). Any one of these would be fine, if all we want is a
raytraced image of a poker game or whatever, one that LOOKS random.

However, there are only 16 possible shufflings out of 52!, or about 8*10^67. So
not every possible shuffling can be acheived from our initial seeds. Not even
close!

But in reality, every possible shuffling could appear from a truly random
process. So the 2^4 seeds are not sufficient to provide a poker hand that comes
from a proper random distribution. It LOOKS completely random, if all you want
is something that "looks" like a random shuffling of a deck. But, for example,
if none of those 16 shuffled decks contains a royal flush for some player, then
no matter how you seed the RNG, no one will EVER get a royal flush.

In other words, if I'm a poker player with money on the line, then I want a game
that guarantees that every possible shuffle of the deck is possible. With only
16 seeds, then the game can only guarantee that the deck will be one of 16
pre-determined random shufflings of the deck. Like I said, the distinction is
subtle, and I suppose some people won't think the distinction matters at all.

Post a reply to this message

clipka nous illumina en ce 2009-05-20 10:54 -->
> 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.
> 
> 
> 
Bummer!

Another possibility:
If the seed is an integer, use the current generator.

If the seed value is a float, use the improved generator. Here, a float would be 
deffined as any value that can't be represented as a 32 bits integer: to big or 
having a fractional part.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   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.

Wasn't there *some* talk about a major rework of the SDL anyway?

So I'd say, never mind about "huge seeds" for now, and leave that up for a
next-generation SDL to take care of.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   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.

> Wasn't there *some* talk about a major rework of the SDL anyway?

> So I'd say, never mind about "huge seeds" for now, and leave that up for a
> next-generation SDL to take care of.

  No, I disagree with the idea that we should simply not support long seeds
for the simple reason that deciding on the handiest syntax is not immediately
obvious. I would certainly want access to the whole RNG even if doing so
would require writing a few more characters.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   No, I disagree with the idea that we should simply not support long seeds
> for the simple reason that deciding on the handiest syntax is not immediately
> obvious. I would certainly want access to the whole RNG even if doing so
> would require writing a few more characters.

.... and me, I'd consider a higher-quality RNG too important to waste time on
special syntax whose sole *real* benefit would be the ability to turn POV-Ray
into a strong cryptographic application or a poker game engine.

BTW, not only users, but also other parts of POV-Ray could benefit from a good
RNG. Subsurface scattering, for instance, currently suffers dearly from the
lack of a good random number source.

You can always wreck your brain on that super-duper-seeding syntax in a later
increment.

I'm not saying "never ever support it" - all I'm saying is "it's not nearly
important enough to waste time on it right now".

Post a reply to this message