[Numpy-discussion] Polynomial evaluation inconsistencies

Maxwell Aifer maifer at haverford.edu
Sat Jun 30 12:13:58 EDT 2018

Thanks, that explains a lot! I didn't realize the reverse ordering actually
originated with matlab's polyval, but that makes sense given the one-based
indexing. I see why it is the way it is, but I still think it would make
more sense for np.polyval() to use conventional indexing (c[0] * x^0 + c[1]
* x^1 + c[2] * x^2). np.polyval() can be convenient when a polynomial
object is just not needed, but if a single program uses both np.polyval()
and np.polynomail.Polynomial, it seems bound to cause unnecessary confusion.


On Fri, Jun 29, 2018 at 11:23 PM, Eric Wieser <wieser.eric+numpy at gmail.com>

> Here's my take on this, but it may not be an accurate summary of the
> history.
> `np.poly<func>` 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 <charlesr.harris at gmail.com>
> wrote:
>> On Fri, Jun 29, 2018 at 8:21 PM, Maxwell Aifer <maifer at haverford.edu>
>> 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
>>>    <https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.polynomial.polynomial.Polynomial.html#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
>>>    <https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.polyval.html>:
>>>    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
>>>    <https://docs.scipy.org/doc/numpy-1.12.0/reference/generated/numpy.polynomial.polynomial.polyval.html>:
>>>    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
>>> <https://www.mathworks.com/help/matlab/ref/polyval.html> 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 at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180630/206225da/attachment.html>

More information about the NumPy-Discussion mailing list