set_random_seed does not seed Python's random number generator

[William Stein]

Hi Sage-Devel,

I was very surprised by this just now:

sage: import random
sage: random.randint(0,20)
0
sage: set_random_seed(0)
sage: random.randint(0,20)
0
sage: set_random_seed(0)
sage: random.randint(0,20)
5
sage: random.seed(0)
sage: random.randint(0,20)
17
sage: random.seed(0)
sage: random.randint(0,20)
17

Basically, I expected that Sage's "set_random_seed" would actually set
*Python*'s own random seed, given that it sets gp, gap, maxima, etc.

I would think this is an obvious serious bug... but since it seems so
blatant, maybe I'm missing something.

William

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Mariah]

This is now trac #12580.

Mariah

[Nils Bruin]

On Feb 22, 1:46 pm, William Stein <wst...@gmail.com> wrote:
> I would think this is an obvious serious bug... but since it seems so
> blatant, maybe I'm missing something.

See #12580. It looks like it was Witty's design to wrap python's
random rather than set global state immediately. He probably had good
reasons to do so.

[William Stein]

But what was it? Since he is MIA, we might not ever know...

William

>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

[Nils Bruin]

On Feb 24, 3:17 pm, William Stein <wst...@gmail.com> wrote:
[reason for current design]

> But what was it?    Since he is MIA, we might not ever know...

When you look a little at how Python's random.Random is designed, his
design seems a fairly clean solution. Whether it leads to a convenient
interface is another question, of course.

In particular from his description here:

http://www.sagemath.org/doc/reference/sage/misc/randstate.html#generating-random-numbers-in-library-code

it is clear that he was intending to get to a point where the "random
state" of all of sage's components could be reflected in a single
object. This allows not just a convenient way of globally forcing the
system into a well-defined seed state, but also allows saving and
restoring that state and make context managers (he already did) that
allow random number generation without affecting the seed state
outside. Implementing this consistently requires some discipline on
the side of sage's library, as he discusses.

Python's random.Random objects essentially already implement the
infrastructure for this. So to capture python's random state, the
obvious solution is to make a random.Random object part of sage's
randstate. Sage's "global" current_randstate() is simply an instance
of Sage's general randstate.

Python's random module maintains its own "global" instance in
random._inst and random.randint is simply a rebinding of
random._inst.randint.
Sage's current_randstate().python_random() is not that object.

If you absolutely want to use random.randint *AND* ensure that
set_random_seed affects it, you could include a random.setstate in
set_random_seed. In that case, you probably want to ensure that you
also set

_current_randstate._python_random = random._inst #you can't do this
literally

This probably requires that the randstate constructor takes a flag
parameter "please make the python random component the global python
one". That way, the global sage randstate would really incorporate the
global python random._inst.