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

As an alternative suggestion, how about treating PRNGs
syntactically more like an object, such as

#declare R = prng {type 1 seed 42}

It gives more flexibility to the syntax as the specified
attributes may now depend on the type of PRNG (possibly some
PRNGs could have additional settings such as number of bits
used or similar?).

Obviously, "seed(n)" should be treated as "prng{type 0 seed n}",
although it might print a warning about obsolete syntax.

The seed attribute would be convenient 32-bit seed, but some PRNGs may
support specifying specialized seed values via additional attributes 
long_seed or a different syntax for seed such as "seed {1,2,3,4}".
This syntax could probably be shared for most complex PRNGs.

There may also be additional type-specific attributes for
initializing the complete "state" of a PRNG (from messages in
this thread I infer the state may encompass more information
than even a long seed value?). However, to actually allow
persisting the state, it would be necessary to have a
function such as rand_state(R).

Post a reply to this message

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

I'm just worried that extended syntax for some things might become
ugly and undocumented.

Something like...

PRNG_Id = prng {
   [type pov36 | mersenne_twister]
   seed Float | Float_Id | FloatArray | FloatArray_Id
}
wouldn't be too bad. It's just not 3.6 compatible.

For 3.7 to be 3.6 compatible, it makes sense to have it be

PRNG_Id = seed(Float | Float_Id [, Float | Float_Id [, Array | Array_Id]])

where the second number is an optional PRNG type,
and the first seed number is ignored if there is an array provided
to seed the state with.

Post a reply to this message

Tim Attwood wrote:
> For 3.7 to be 3.6 compatible, it makes sense to have it be

Or, you could just have two ways to create a PRNG stream. One with the old 
syntax, one with the new.

-- 
   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 wrote:
> 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 th
e
> seed is specified as the 1st, 3rd, 4th, etc. parameters, so there's an 
odd
> discontinuity there...
> 
	Well, you could always say that if more than one parameter is 
given, then the first parameter identifies the algorithm and the 
other parameters make up the seed:

// Same as now:
#declare S1 = seed (1234);

// Equivalent to the above:
#declare S2 = seed (1, 1234);

// Use new algorithm number 2 with a longer seed:
#declare S3 = seed (2, 1234, 5678);

		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)