[Python-ideas] Python's Source of Randomness and the random.py module Redux
Andrew Barnert
abarnert at yahoo.com
Fri Sep 11 12:07:27 CEST 2015
On Sep 11, 2015, at 02:52, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Fri, Sep 11, 2015 at 1:02 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> On 11 September 2015 at 05:44, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>>> I suppose it would be too magic to have the seed method substitute the
>>> traditional PRNG for the default, while an implicitly seeded RNG
>>> defaults to a crypto strong algorithm?
>>
>> One issue with that - often, programs simply use a RNG for their own
>> purposes, but offer a means of getting the seed after the fact for
>> reproducibility reasons (the "map seed" case, for example).
>>
>> Pseudo-code:
>>
>> if <user supplied a "seed">:
>> state = <user-supplied value>
>> random.setstate(state)
>> else:
>> state = random.getstate()
>> ... do the program's main job, never calling seed/setstate
>> if <user requests the "seed">:
>> print state
>>
>> So getstate (and setstate) would also need to switch to a PRNG.
>>
>> There's actually very few cases I can think of where I'd need seed()
>> (as opposed to setstate()). Maybe if I let the user *choose* a seed
>> Some games do this.
>
> You don't really want to use the full 4992 byte state for a "map seed"
> application anyway (type 'random.getstate()' in a REPL and watch your
> terminal scroll down multiple pages...). No game actually uses map
> seeds that look anything like that.
But games do store the entire map state with saved games if they want repeatable saves (e.g., to prevent players from defeating the RNG by save scumming).
More information about the Python-ideas
mailing list