[SciPy-dev] Re: [Numpy-discussion] Release of scipy core betawillhappen next week.

Robert Kern rkern at ucsd.edu
Tue Sep 27 19:11:06 CDT 2005


Charles Harris wrote:
> Robert Kern wrote
> 
>>with minimal change. It passes around state in a plain C struct rather
>>than a PyObject*, which is good, because I needed to extend that struct.
> 
> This is potentially a problem if the user has, say, a uniform double and a
> random integer going at the same time. There should be no correlation between
> the two, so they need to be using the same base generator, or two different
> generators with genuinely random seeds. I kept one base generator per module
> to deal with this, but I guess there might be a better way to keep things straight.

Actually, it's the *solution* to that problem. Unlike the older
RANLIB-based modules, random.py and mtrand define generator objects that
keep their state tied to the object. You can instantiate them as many
times as you like with different states (another benefit of the
/dev/urandom seeding over seeding with the time; there's no real chance
that you'll seed two generators with the same state no matter how close
in time you instantiate them). There are no globals. Give me a little
bit of time to check it in and you can see for yourself.

I do instantiate one generator in the module and make aliases to its
methods for convenience. People who just need a random number here and
there will probably use those. People who have need more control can
instantiate their own generator.

I do have one question on this point, though: Should this default
generator be initialized with the same state (like scipy.lib.rng) or be
initialized via /dev/urandom or time (like scipy.lib.ranlib and
random.py)? I have 4992 hex digits of pi that are begging to be used.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter




More information about the Scipy-dev mailing list