Pierre-Andre Noel noel.pierre.an...@gmail.com wrote:
Why not do something like the C++11 random? In random, a generator
is the engine producing randomness, and a distribution decides what is
the type of outputs that you want.
This is what randomkit is doing internally, which is why it is
Julian Taylor jtaylor.deb...@googlemail.com wrote:
But as already mentioned by Robert, we know what we can do, what is
missing is someone writting the code.
This is actually a part of NumPy I know in detail, so I will be able to
contribute. Robert Kern's last post about objects like
On 8 Sep 2014 14:43, Robert Kern robert.k...@gmail.com wrote:
On Mon, Sep 8, 2014 at 6:05 PM, Pierre-Andre Noel
noel.pierre.an...@gmail.com wrote:
I think we could add new generators to NumPy though,
perhaps with a keyword to control the algorithm (defaulting to the
current
On 09/09/14 20:08, Nathaniel Smith wrote:
There's also another reason why generator decisions should be part of
the RandomState object itself: we may want to change the distribution
methods themselves over time (e.g., people have been complaining for a
while that we use a suboptimal method
On Sun, Sep 7, 2014 at 4:23 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Benjamin Root ben.r...@ou.edu wrote:
In addition to issues with reproducibility, think of all of the unit
tests
that would break!
That is a reproducibility problem :)
I think we could add new generators to NumPy though,
perhaps with a keyword to control the algorithm (defaulting to the
current
Mersenne Twister).
Why not do something like the C++11 random? In random, a generator
is the engine producing randomness, and a distribution decides what is
the
On 08.09.2014 19:05, Pierre-Andre Noel wrote:
I think we could add new generators to NumPy though,
perhaps with a keyword to control the algorithm (defaulting to the
current
Mersenne Twister).
...
Here is how I propose to adapt this scheme to numpy. First, there would
be a global
On Mon, Sep 8, 2014 at 6:05 PM, Pierre-Andre Noel
noel.pierre.an...@gmail.com wrote:
I think we could add new generators to NumPy though,
perhaps with a keyword to control the algorithm (defaulting to the
current
Mersenne Twister).
Why not do something like the C++11 random? In random,
In addition to issues with reproducibility, think of all of the unit tests
that would break!
On Sun, Sep 7, 2014 at 3:51 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
James A. Bednar jbed...@inf.ed.ac.uk wrote:
Please don't ever, ever break the sequence of numpy's random numbers!
Benjamin Root ben.r...@ou.edu wrote:
In addition to issues with reproducibility, think of all of the unit tests
that would break!
That is a reproducibility problem :)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
| Date: Fri, 05 Sep 2014 13:19:57 -0400
| From: Neal Becker ndbeck...@gmail.com
|
| I think it's somewhat debatable whether generating a different
| sequence of random numbers counts as breaking backward
| compatibility.
Please don't ever, ever break the sequence of numpy's random numbers!
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker ndbeck...@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
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker ndbeck...@gmail.com wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker ndbeck...@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
Robert Kern wrote:
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker ndbeck...@gmail.com wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker ndbeck...@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?
On Fri, Sep 5, 2014 at 6:19 PM, Neal Becker ndbeck...@gmail.com wrote:
Robert Kern wrote:
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker ndbeck...@gmail.com wrote:
Robert Kern wrote:
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker ndbeck...@gmail.com wrote:
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
On 9/5/2014 1:19 PM, Neal Becker wrote:
I think it's somewhat debatable whether generating a different sequence of
random numbers counts as breaking backward compatibility.
Please: it does.
Alan Isaac
___
NumPy-Discussion mailing list
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
On Fri, Sep 5, 2014 at 9:36 PM, Sturla Molden sturla.mol...@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
Robert Kern robert.k...@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
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker ndbeck...@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
___
NumPy-Discussion mailing list
22 matches
Mail list logo
