Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   Let me as you the reverse question: Why should we *not* offer large
>>> seeds? Why limit the usability of the RNGs for no good reason?
> 
>> It disturbs the syntax of the seed() call that exists even more. So it's 
>> mostly a matter that you already addressed: the syntax is ugly.
> 
>   But it's not like you would notice if you don't care about the extra
> long seeds. If you are content with the 32-bit seeds, you can use seed()
> in the exact same way as now. The long seeds would just be an extra which
> doesn't disturb the currently existing syntax.

Certainly. You asked what was wrong. It's not a big problem. It's just 
slightly ugly, because you're trying to take a function that currently takes 
one seed-number, and turn it into a function that takes an optional PRNG 
identifier and a variable number of seed numbers. That's hard to do, 
syntactically, without making things ugly (such as by passing a single value 
that's actually a collection of values).

I'm just saying, perhaps having a different function would make it less 
ugly, as well as leaving open the possibility of being able to save and 
recall the PRNG's state. As Mr Berger pointed out, being able to dump out 
the state and reload it would be good too.  Whether you can do the 
dump/reload with the same function that sets the seed is another question, 
tho. I would imagine some PRNGs (RC4 leaps to mind) might take a state that 
needs to be in a specific form.

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?

seed(23)
seed("18D8237")

That would seem to allow for the maximum number of bytes in a seed without a 
problem. If you made the state dump/reload also provide/require a similar 
string, you could easily write it to a file, ship it to macros, etc.

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