[Numpy-discussion] python is cool

2015-05-12 Thread Neal Becker
In order to make sure all my random number generators have good 
independence, it is a good practice to use a single shared instance (because 
it is already known to have good properties).  A less-desirable alternative 
is to used rng's seeded with different starting states - in this case the 
independence properties are not generally known.

So I have some fairly deeply nested data structures (classes) that somewhere 
contain a reference to a RandomState object.

I need to be able to clone these data structures, producing new independent 
copies, but I want the RandomState part to be the shared, singleton rs 
object.

In python, no problem:

---
from numpy.random import RandomState

class shared_random_state (RandomState):
def __init__ (self, rs):
RandomState.__init__(self, rs)

def __deepcopy__ (self, memo):
return self
---

Now I can copy.deepcopy the data structures, but the randomstate part is 
shared.  I just use

rs = shared_random_state (random.RandomState(0))

and provide this rs to all my other objects.  Pretty nice!

-- 
Those who fail to understand recursion are doomed to repeat it

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] python is cool

2015-05-12 Thread Neal Becker
Roland Schulz wrote:

 Hi,
 
 I think the best way to solve this issue to not use a state at all. It is
 fast, reproducible even in parallel (if wanted), and doesn't suffer from
 the shared issue. Would be nice if numpy provided such a stateless RNG as
 implemented in Random123: www.deshawresearch.com/resources_random123.html
 
 Roland

That is interesting.  I think np.random needs to be refactored, so it can 
accept a pluggable rng - then we could switch the underlying rng.

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] python is cool

2015-05-12 Thread Roland Schulz
Hi,

I think the best way to solve this issue to not use a state at all. It is
fast, reproducible even in parallel (if wanted), and doesn't suffer from
the shared issue. Would be nice if numpy provided such a stateless RNG as
implemented in Random123: www.deshawresearch.com/resources_random123.html

Roland

On Tue, May 12, 2015 at 2:18 PM, Neal Becker ndbeck...@gmail.com wrote:

 In order to make sure all my random number generators have good
 independence, it is a good practice to use a single shared instance
 (because
 it is already known to have good properties).  A less-desirable alternative
 is to used rng's seeded with different starting states - in this case the
 independence properties are not generally known.

 So I have some fairly deeply nested data structures (classes) that
 somewhere
 contain a reference to a RandomState object.

 I need to be able to clone these data structures, producing new independent
 copies, but I want the RandomState part to be the shared, singleton rs
 object.

 In python, no problem:

 ---
 from numpy.random import RandomState

 class shared_random_state (RandomState):
 def __init__ (self, rs):
 RandomState.__init__(self, rs)

 def __deepcopy__ (self, memo):
 return self
 ---

 Now I can copy.deepcopy the data structures, but the randomstate part is
 shared.  I just use

 rs = shared_random_state (random.RandomState(0))

 and provide this rs to all my other objects.  Pretty nice!

 --
 Those who fail to understand recursion are doomed to repeat it

 ___
 NumPy-Discussion mailing list
 NumPy-Discussion@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion




-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion