[Numpy-discussion] Polynomial evaluation inconsistencies

Hi, I noticed some frustrating inconsistencies in the various ways to evaluate polynomials using numpy. Numpy has three ways of evaluating polynomials (that I know of) and each of them has a different syntax: - numpy.polynomial.polynomial.Polynomial

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

Note that this is the first formal proposal to accept a NEP using our new process (yay!). While writing it I realized that the current text about this in NEP 0 is a bit terse, so I've also just submitted a PR to expand that section: https://github.com/numpy/numpy/pull/11459 -n On Fri, Jun 29,

[Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

Hi all, I propose that we accept NEP 15: Merging multiarray and umath: http://www.numpy.org/neps/nep-0015-merge-multiarray-umath.html The core part of this proposal was uncontroversial. The main point of discussion was whether it was OK to deprecate set_numeric_ops, or whether it had some

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

Here's my take on this, but it may not be an accurate summary of the history. `np.poly` is part of the original matlab-style API, built around `poly1d` objects. This isn't a great design, because they represent: p(x) = c[0] * x^2 + c[1] * x^1 + c[2] * x^0 For this reason, among others, the

Re: [Numpy-discussion] rackspace ssl certificates

On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris wrote: > > > On Tue, Jun 26, 2018 at 3:55 PM, Matthew Brett > wrote: >> >> Hi, >> >> On Tue, Jun 26, 2018 at 10:43 PM, Matti Picus >> wrote: >> > On 19/06/18 10:57, Matthew Brett wrote: >> >> >> >> Hi, >> >> >> >> On Tue, Jun 19, 2018 at 6:27

Re: [Numpy-discussion] Proposal to accept NEP 15: Merging multiarray and umath

On Fri, Jun 29, 2018 at 3:28 PM, Marten van Kerkwijk wrote: > Agreed on accepting the NEP! But it is not the first proposal to accept > under the new rules - that goes to the broadcasting NEP (though perhaps I > wasn't sufficiently explicit in stating that I was starting a > count-down...). --

Re: [Numpy-discussion] rackspace ssl certificates

On Fri, Jun 29, 2018 at 4:35 PM, Matthew Brett wrote: > On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris > wrote: > > > > > > On Tue, Jun 26, 2018 at 3:55 PM, Matthew Brett > > wrote: > >> > >> Hi, > >> > >> On Tue, Jun 26, 2018 at 10:43 PM, Matti Picus > >> wrote: > >> > On 19/06/18 10:57,

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

Good catch, I think the latter failing is because np.add.reduce ends up calling np.ufunc.reduce.__get__(np.add), and builtin_function.__get__ doesn’t appear to do any caching. I suppose caching bound methods would just be a waste of time. == would work just fine in my suggestion above, it seems -

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

On Fri, Jun 29, 2018 at 8:21 PM, Maxwell Aifer wrote: > Hi, > I noticed some frustrating inconsistencies in the various ways to evaluate > polynomials using numpy. Numpy has three ways of evaluating polynomials > (that I know of) and each of them has a different syntax: > >- > >

Re: [Numpy-discussion] rackspace ssl certificates

On Tue, Jun 26, 2018 at 3:55 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 26, 2018 at 10:43 PM, Matti Picus > wrote: > > On 19/06/18 10:57, Matthew Brett wrote: > >> > >> Hi, > >> > >> On Tue, Jun 19, 2018 at 6:27 PM, Matti Picus > >> wrote: > >>> > >>> On 19/06/18 09:58, Charles R Harris

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

On Thu, Jun 28, 2018 at 5:36 PM Eric Wieser wrote: > Another option would be to directly compare the methods against known ones: > > obj = func.__self__ > if isinstance(obj, np.ufunc): > if func is obj.reduce: > got_reduction() > > I'm not quite sure why, but this doesn't seem to