Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-29 Thread Eric Wieser 
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 `np.polynomial` module was created,
starting with a clean slate. The core of this is
`np.polynomial.Polynomial`. There, everything uses the convention

p(x) = c[0] * x^0 + c[1] * x^1 + c[2] * x^2

It sounds like we might need clearer docs explaining the difference, and
pointing users to the more sensible `np.polynomial.Polynomial`

Eric



On Fri, 29 Jun 2018 at 20:10 Charles R Harris 
wrote:

> 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:
>>
>>-
>>
>>numpy.polynomial.polynomial.Polynomial
>>
>> :
>>You define a polynomial by a list of coefficients *in order of
>>increasing degree*, and then use the class’s call() function.
>>-
>>
>>np.polyval
>>
>> :
>>Evaluates a polynomial at a point. *First* argument is the
>>polynomial, or list of coefficients *in order of decreasing degree*,
>>and the *second* argument is the point to evaluate at.
>>-
>>
>>np.polynomial.polynomial.polyval
>>
>> :
>>Also evaluates a polynomial at a point, but has more support for
>>vectorization. *First* argument is the point to evaluate at, and
>>*second* argument the list of coefficients *in order of increasing
>>degree*.
>>
>> Not only the order of arguments is changed between different methods, but
>> the order of the coefficients is reversed as well, leading to puzzling bugs
>> (in my experience). What could be the reason for this madness? As polyval
>> is a shameless ripoff of Matlab’s function of the same name
>>  anyway, why not
>> just use matlab’s syntax (polyval([c0, c1, c2...], x)) across the board?
>> ​
>>
>>
> The polynomial package, with its various basis, deals with series, and
> especially with the truncated series approximations that are used in
> numerical work. Series are universally written in increasing order of the
> degree. The Polynomial class is efficient in a single variable, while the
> numpy.polynomial.polynomial.polyval function is intended as a building
> block and can also deal with multivariate polynomials or multidimensional
> arrays of polynomials, or a mix. See the simple implementation of polyval3d
> for an example. If you are just dealing with a single variable, use
> Polynomial, which will also track scaling and offsets for numerical
> stability and is generally much superior to the simple polyval function
> from a numerical point of view.
>
> As to the ordering of the degrees, learning that the degree matches the
> index is pretty easy and is a more natural fit for the implementation code,
> especially as the number of variables increases. I note that Matlab has
> ones based indexing, so that was really not an option for them.
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-29 Thread Charles R Harris 
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:
>
>-
>
>numpy.polynomial.polynomial.Polynomial
>
> :
>You define a polynomial by a list of coefficients *in order of
>increasing degree*, and then use the class’s call() function.
>-
>
>np.polyval
>
> :
>Evaluates a polynomial at a point. *First* argument is the polynomial,
>or list of coefficients *in order of decreasing degree*, and the
>*second* argument is the point to evaluate at.
>-
>
>np.polynomial.polynomial.polyval
>
> :
>Also evaluates a polynomial at a point, but has more support for
>vectorization. *First* argument is the point to evaluate at, and
>*second* argument the list of coefficients *in order of increasing
>degree*.
>
> Not only the order of arguments is changed between different methods, but
> the order of the coefficients is reversed as well, leading to puzzling bugs
> (in my experience). What could be the reason for this madness? As polyval
> is a shameless ripoff of Matlab’s function of the same name
>  anyway, why not
> just use matlab’s syntax (polyval([c0, c1, c2...], x)) across the board?
> ​
>
>
The polynomial package, with its various basis, deals with series, and
especially with the truncated series approximations that are used in
numerical work. Series are universally written in increasing order of the
degree. The Polynomial class is efficient in a single variable, while the
numpy.polynomial.polynomial.polyval function is intended as a building
block and can also deal with multivariate polynomials or multidimensional
arrays of polynomials, or a mix. See the simple implementation of polyval3d
for an example. If you are just dealing with a single variable, use
Polynomial, which will also track scaling and offsets for numerical
stability and is generally much superior to the simple polyval function
from a numerical point of view.

As to the ordering of the degrees, learning that the degree matches the
index is pretty easy and is a more natural fit for the implementation code,
especially as the number of variables increases. I note that Matlab has
ones based indexing, so that was really not an option for them.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-29 Thread Maxwell Aifer 
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
   
:
   You define a polynomial by a list of coefficients *in order of
   increasing degree*, and then use the class’s call() function.
   -

   np.polyval
   
:
   Evaluates a polynomial at a point. *First* argument is the polynomial,
   or list of coefficients *in order of decreasing degree*, and the *second*
   argument is the point to evaluate at.
   -

   np.polynomial.polynomial.polyval
   
:
   Also evaluates a polynomial at a point, but has more support for
   vectorization. *First* argument is the point to evaluate at, and *second*
   argument the list of coefficients *in order of increasing degree*.

Not only the order of arguments is changed between different methods, but
the order of the coefficients is reversed as well, leading to puzzling bugs
(in my experience). What could be the reason for this madness? As polyval
is a shameless ripoff of Matlab’s function of the same name
 anyway, why not
just use matlab’s syntax (polyval([c0, c1, c2...], x)) across the board?
​
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

2018-06-29 Thread Eric Wieser 
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 - irrespective of
the resolution of the discussion on python-dev.

Eric
​

On Fri, 29 Jun 2018 at 18:24 Stephan Hoyer  wrote:

> 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 work with current ufunc
> objects:
>
> >>> np.add.reduce == np.add.reduce  # OK
> True
>
> >>> np.add.reduce is np.add.reduce  # what?!?
> False
>
> Maybe this is a bug? There's been some somewhat related discussion
> recently on python-dev:
> https://mail.python.org/pipermail/python-dev/2018-June/153959.html
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

2018-06-29 Thread Stephan Hoyer 
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 work with current ufunc
objects:

>>> np.add.reduce == np.add.reduce  # OK
True

>>> np.add.reduce is np.add.reduce  # what?!?
False

Maybe this is a bug? There's been some somewhat related discussion recently
on python-dev:
https://mail.python.org/pipermail/python-dev/2018-June/153959.html
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] rackspace ssl certificates

2018-06-29 Thread Charles R Harris 
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, 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 wrote:
> >> >
> >> > What I was curious about is that there were no more "daily" builds
> >> > of
> >> > master.
> >> 
> >>  Is that right?  That there were daily builds of master, on
> Appveyor?
> >>  I don't know how those worked, I only recently got cron permission
> >>  ...
> >> >>>
> >> >>>
> >> >>> No, but there used to be daily builds on travis. They stopped 8 days
> >> >>> ago,
> >> >>> https://travis-ci.org/MacPython/numpy-wheels/builds.
> >> >>
> >> >> Oops - yes - sorry - I retired the 'daily' branch, in favor of
> >> >> 'master', but forgot to update the Travis-CI settings.
> >> >>
> >> >> Done now.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Matthew
> >> >>
> >> > FWIW, still no daily builds at
> >> > https://travis-ci.org/MacPython/numpy-wheels/builds
> >>
> >> You mean, some days there appears to be no build?  The build matrix
> >> does show Cron-triggered jobs, the last of which was a few hours ago:
> >> https://travis-ci.org/MacPython/numpy-wheels/builds/397008012
> >>
> >> Cheers,
> >>
> >> Matthew
> >
> >
> > The cron wheels are getting built and tested, but they aren't uploading
> to
> > rackspace.
>
> The cron wheels go to the "pre" container at
> https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a
> 83.ssl.cf2.rackcdn.com
>
>
Ah, there they are ... except ... you cancelled the builds I was waiting
for :) I was building wheels so we could have folks test the DLL load
problem, which I'm pretty sure if fixed anyway, so I suppose waiting on the
daily isn't a big a deal.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

2018-06-29 Thread Nathaniel Smith 
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...). -- Marten

Oh sorry, I missed that! (Which I guess is some evidence in favor of
starting a new thread :-).)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] rackspace ssl certificates

2018-06-29 Thread Matthew Brett 
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 PM, Matti Picus 
>> >> wrote:
>> >>>
>> >>> On 19/06/18 09:58, Charles R Harris wrote:
>> >
>> > What I was curious about is that there were no more "daily" builds
>> > of
>> > master.
>> 
>>  Is that right?  That there were daily builds of master, on Appveyor?
>>  I don't know how those worked, I only recently got cron permission
>>  ...
>> >>>
>> >>>
>> >>> No, but there used to be daily builds on travis. They stopped 8 days
>> >>> ago,
>> >>> https://travis-ci.org/MacPython/numpy-wheels/builds.
>> >>
>> >> Oops - yes - sorry - I retired the 'daily' branch, in favor of
>> >> 'master', but forgot to update the Travis-CI settings.
>> >>
>> >> Done now.
>> >>
>> >> Cheers,
>> >>
>> >> Matthew
>> >>
>> > FWIW, still no daily builds at
>> > https://travis-ci.org/MacPython/numpy-wheels/builds
>>
>> You mean, some days there appears to be no build?  The build matrix
>> does show Cron-triggered jobs, the last of which was a few hours ago:
>> https://travis-ci.org/MacPython/numpy-wheels/builds/397008012
>>
>> Cheers,
>>
>> Matthew
>
>
> The cron wheels are getting built and tested, but they aren't uploading to
> rackspace.

The cron wheels go to the "pre" container at
https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com

Cheers,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] rackspace ssl certificates

2018-06-29 Thread Charles R Harris 
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 wrote:
> >
> > What I was curious about is that there were no more "daily" builds of
> > master.
> 
>  Is that right?  That there were daily builds of master, on Appveyor?
>  I don't know how those worked, I only recently got cron permission ...
> >>>
> >>>
> >>> No, but there used to be daily builds on travis. They stopped 8 days
> ago,
> >>> https://travis-ci.org/MacPython/numpy-wheels/builds.
> >>
> >> Oops - yes - sorry - I retired the 'daily' branch, in favor of
> >> 'master', but forgot to update the Travis-CI settings.
> >>
> >> Done now.
> >>
> >> Cheers,
> >>
> >> Matthew
> >>
> > FWIW, still no daily builds at
> > https://travis-ci.org/MacPython/numpy-wheels/builds
>
> You mean, some days there appears to be no build?  The build matrix
> does show Cron-triggered jobs, the last of which was a few hours ago:
> https://travis-ci.org/MacPython/numpy-wheels/builds/397008012
>
> Cheers,
>
> Matthew
>

The cron wheels are getting built and tested, but they aren't uploading to
rackspace.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

2018-06-29 Thread Nathaniel Smith 
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, 2018 at 3:18 PM, Nathaniel Smith  wrote:
> 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 legitimate use cases. The conclusion was that in
> all the cases where set_numeric_ops is useful,
> PyUFunc_ReplaceLoopBySignature is a strictly better alternative, so
> there's no reason not to deprecate set_numeric_ops. So at this point I
> think the whole proposal is uncontroversial, and we can go ahead and
> accept it.
>
> If there are no substantive objections within 7 days from this email,
> then the NEP will be accepted; see NEP 0 for more details:
> http://www.numpy.org/neps/nep-.html
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org



-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

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

2018-06-29 Thread Nathaniel Smith 
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 legitimate use cases. The conclusion was that in
all the cases where set_numeric_ops is useful,
PyUFunc_ReplaceLoopBySignature is a strictly better alternative, so
there's no reason not to deprecate set_numeric_ops. So at this point I
think the whole proposal is uncontroversial, and we can go ahead and
accept it.

If there are no substantive objections within 7 days from this email,
then the NEP will be accepted; see NEP 0 for more details:
http://www.numpy.org/neps/nep-.html

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion