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