I am not sure if this is the right place to discuss this issue. However,
I problem I keep running into in Monte Carlo simulations is generating
pseudorandom numbers with multiple threads. PRNGs such as the Mersenne
Twister keep an internal state, which prevents the PRNG from being
re-entrant
On Fri, Aug 21, 2009 at 17:48, Sturla Moldenstu...@molden.no wrote:
I am not sure if this is the right place to discuss this issue. However,
I problem I keep running into in Monte Carlo simulations is generating
pseudorandom numbers with multiple threads. PRNGs such as the Mersenne
Twister
Robert Kern skrev:
Although you don't really have re-entrancy issues, you will usually
want one PRNG per thread for determinism.
I see... numpy.random.rand does not have re-entrancy issues because of
the GIL, but I get indeterminism from the OS scheduling the threads.
RandomState might not
Sturla Molden skrev:
It seems there is a special version of the Mersenne Twister for this.
The code is LGPL (annoying for SciPy but ok for me).
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/DC/dgene.pdf
http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/DC/dgene.pdf
Basically it encodes the
Xavier Saint-Mleux skrev:
Of course, the mathematically correct way would be to use a correct
jumpahead function, but all the implementations that I know of are GPL.
A recent article about this is:
www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpmt.pdf
I know of no efficient jumpahead
