Julian Taylor 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 np.random.SFMT()
working similar to R
Pierre-Andre Noel wrote:
> Why not do something like the C++11 ? In , 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 so easy to
plug in a different gen
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 8 Sep 2014 14:43, "Robert Kern" wrote:
>
> On Mon, Sep 8, 2014 at 6:05 PM, 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).
> >
> > Why not do s
On Mon, Sep 8, 2014 at 6:05 PM, 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).
>
> Why not do something like the C++11 ? In , a "generator"
> is the engine
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
> b
> 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 ? In , a "generator"
is the engine producing randomness, and a "distribution" decides what is
the type
On Sun, Sep 7, 2014 at 4:23 PM, Sturla Molden
wrote:
> Benjamin Root wrote:
> > In addition to issues with reproducibility, think of all of the unit
> tests
> > that would break!
>
> That is a reproducibility problem :)
>
> ___
> NumPy-Discussion maili
Benjamin Root 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
http://mail.scipy.org/mailman/listin
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
wrote:
> "James A. Bednar" wrote:
>
> > Please don't ever, ever break the sequence of numpy's random numbers!
> > Please! We have put a lot of effort into
"James A. Bednar" wrote:
> Please don't ever, ever break the sequence of numpy's random numbers!
> Please! We have put a lot of effort into being able to reproduce our
> published work exactly,
Jup, it cannot be understated how important this is for reproducibility of
published research. Thus
| Date: Fri, 05 Sep 2014 13:19:57 -0400
| From: Neal Becker
|
| 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!
Please! We have pu
Robert Kern 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
On Fri, Sep 5, 2014 at 9:36 PM, Sturla Molden 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 rath
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 dist
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
NumPy-Discuss
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 sequenc
On Fri, Sep 5, 2014 at 6:19 PM, Neal Becker wrote:
> Robert Kern wrote:
>
>> On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker wrote:
>>> Robert Kern wrote:
>>>
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker wrote:
> http://www.math.sci.hiroshima-u.ac.jp/~%20m-mat/MT/SFMT/index.html
Robert Kern wrote:
> On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker wrote:
>> Robert Kern wrote:
>>
>>> On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker 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
On Fri, Sep 5, 2014 at 12:05 PM, Neal Becker wrote:
> Robert Kern wrote:
>
>> On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker 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
Robert Kern wrote:
> On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker 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
--
--
On Thu, Sep 4, 2014 at 12:32 PM, Neal Becker 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
NumPy-Discussion@scipy.org
http://mail.scipy
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
23 matches
Mail list logo
