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)

Warp wrote:
>   The RNG I'm considering supports very large seeds (up to something li
ke
> 8192-bit seeds if so configured) and has very high quality and speed.
> 
	As a simple matter of curiosity, which RNG are you considering?

		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)

Among other things, Warp saw fit to write:

> 3) Use an alternative function for long seeds. For example:
> 
>      #declare S = longseed(2, 1, 2, 3, 4);
> 
> [...]
> 
> 4) Create an entirely new syntax for specifying a group of values. This,
>    however, would be laborious and should preferably be avoided.

Somewhere between 3 and 4:

3.5) Create a sort of "concatenate numbers" function, that would allow
really large numbers, maybe with and arbitrary number of parameters. If the
function is named "numconcat":

seed(1234)   // current
seed(1234,1) // same as above
seed(1234,2) // new RNG with small seed
seed(numconcat(1234,5678,90),2) // new RNG with large seed

The function numconcat need not be a "real" concatenation, i.e., there's no
reason why numconcat(1234,5678,90)=1234567890, it should just create a
large number out of smaller ones.

Hmm... maybe that's what option 4 meant from the beginning, though.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Tim Attwood <tim### [at] anti-spamcomcastnet> wrote:
> PRNG_Id = seed(Float | Float_Id [, Float | Float_Id [, Array | Array_Id]])

  Btw, just use "float expression" to indicate anything that evaluates to
float in a comprehensive way.

-- 
                                                          - Warp

Post a reply to this message

> [-- text/plain, encoding quoted-printable, charset: UTF-8, 14 lines --]

> Warp wrote:
> >   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.
> > 
>         As a simple matter of curiosity, which RNG are you considering?

  The ISAAC RNG, of which I have some experience and have found to be of
very decent quality (should be rather cryptographically strong) and very
fast, and with a very large period. Also according to my experience it's
faster than Mersenne Twister without the need for special compiler options
(the MT can be made as fast, but only if you create a special SSE version
of it).

  (Of course speed is not really crucial here, but the quality should be
very good.)

-- 
                                                          - Warp

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> #declare R = prng {type 1 seed 42}

  I'm not sure if with the POV-Ray parser that 'seed' keyword would cause
a clash with the seed() function. Some names can be used in different
contexts, but I'm not sure this is one of those cases.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   (Of course speed is not really crucial here, but the quality should be
> very good.)

Given that there might be some good use for a more sophisticated RNG inside
POV-Ray's rendering engine possibly heading our way (thinking of SSLT here, or
maybe addition of some montecarlo elements), I guess speed *should* be
considered an issue.

So to hear that the RNG you have in mind *is* fairly fast, that's good news.

Post a reply to this message