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

[Travis Oliphant]

Robert Kern wrote:

>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.
>
>  
>
I think it should be initialized via /dev/urandom or time.

Thanks for your help.   Should I delay release of the beta until you get 
your code contributed?

I'm ready to go with most else.

-Travis