SFMT (faster mersenne twister)
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html -- -- Those who don't understand recursion are doomed to repeat it
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker <ndbecker2@gmail.com> wrote:
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
What would you like to say about it? -- Robert Kern
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker <ndbecker2@gmail.com> wrote:
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
What would you like to say about it?
If it is faster (and at least as good), maybe we'd like to adopt it to replace that used for mtrand -- -- Those who don't understand recursion are doomed to repeat it
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker <ndbecker2@gmail.com> wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker <ndbecker2@gmail.com> wrote:
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
What would you like to say about it?
If it is faster (and at least as good), maybe we'd like to adopt it to replace that used for mtrand
It's a variant of the standard MT rather than just an implementation of it, so we can't just drop it in. You will need to build the infrastructure to support multiple PRNGs first (or rather, build the infrastructure to reuse the non-uniform distribution code with multiple core PRNGs). -- Robert Kern
Robert Kern wrote:
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker <ndbecker2@gmail.com> wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker <ndbecker2@gmail.com> wrote:
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
What would you like to say about it?
If it is faster (and at least as good), maybe we'd like to adopt it to replace that used for mtrand
It's a variant of the standard MT rather than just an implementation of it, so we can't just drop it in. You will need to build the infrastructure to support multiple PRNGs first (or rather, build the infrastructure to reuse the non-uniform distribution code with multiple core PRNGs).
You mean it's not backward compatible because it won't generate exactly the same sequence of output for a given seed, and therefore we wouldn't want to make that change? I think it's somewhat debatable whether generating a different sequence of random numbers counts as breaking backward compatibility. -- -- Those who don't understand recursion are doomed to repeat it
On 09/05/2014 01:19 PM, Neal Becker wrote:
You mean it's not backward compatible because it won't generate exactly the same sequence of output for a given seed, and therefore we wouldn't want to make that change?
I think it's somewhat debatable whether generating a different sequence of random numbers counts as breaking backward compatibility.
For regression tests it's essential to be able to generate the same sequence of values from a pseudo-random number generator. Phil
On Fri, Sep 5, 2014 at 6:19 PM, Neal Becker <ndbecker2@gmail.com> wrote:
Robert Kern wrote:
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker <ndbecker2@gmail.com> wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker <ndbecker2@gmail.com> wrote:
http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
What would you like to say about it?
If it is faster (and at least as good), maybe we'd like to adopt it to replace that used for mtrand
It's a variant of the standard MT rather than just an implementation of it, so we can't just drop it in. You will need to build the infrastructure to support multiple PRNGs first (or rather, build the infrastructure to reuse the non-uniform distribution code with multiple core PRNGs).
You mean it's not backward compatible because it won't generate exactly the same sequence of output for a given seed, and therefore we wouldn't want to make that change?
I think it's somewhat debatable whether generating a different sequence of random numbers counts as breaking backward compatibility.
It's not a matter of debate over the semantics of the term "backwards compatibility". This is a policy that we have explicitly chosen for numpy.random (distinct from our backwards compatibility policy for the rest of numpy) because it was requested of us. -- Robert Kern
On 05/09/14 19:19, Neal Becker wrote:
It's a variant of the standard MT rather than just an implementation of it, so we can't just drop it in. You will need to build the infrastructure to support multiple PRNGs first (or rather, build the infrastructure to reuse the non-uniform distribution code with multiple core PRNGs).
You mean it's not backward compatible because it won't generate exactly the same sequence of output for a given seed, and therefore we wouldn't want to make that change?
I thought he meant that the standard MT and SFMT have global states, whereas NumPy's randomkit MT does not. Because of this, NumPy allows you to use multiple RandomState instances. With a vanilla MT or SFMT there would be just one. Sturla
On Fri, Sep 5, 2014 at 9:36 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 05/09/14 19:19, Neal Becker wrote:
It's a variant of the standard MT rather than just an implementation of it, so we can't just drop it in. You will need to build the infrastructure to support multiple PRNGs first (or rather, build the infrastructure to reuse the non-uniform distribution code with multiple core PRNGs).
You mean it's not backward compatible because it won't generate exactly the same sequence of output for a given seed, and therefore we wouldn't want to make that change?
I thought he meant that the standard MT and SFMT have global states, whereas NumPy's randomkit MT does not. Because of this, NumPy allows you to use multiple RandomState instances. With a vanilla MT or SFMT there would be just one.
No, that is not what I meant. If the SFMT can be made to output the same bitstream for the same seed, we can use it (modifying it if necessary to avoid global state if necessary), but it does not look so to me. I welcome corrections on that count (in PR form, preferably!). -- Robert Kern
Robert Kern <robert.kern@gmail.com> wrote:
No, that is not what I meant. If the SFMT can be made to output the same bitstream for the same seed, we can use it (modifying it if necessary to avoid global state if necessary), but it does not look so to me. I welcome corrections on that count (in PR form, preferably!).
Saito's SFMT master thesis says SFMT as a different equidistribution, so it will not give the same bitstream. But it also mentions a SIMD version of the standard MT.
participants (5)
-
Alan G Isaac -
Neal Becker -
Phil Hodge -
Robert Kern -
Sturla Molden