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.
Max On Fri, Jun 29, 2018 at 11:23 PM, Eric Wieser <wieser.eric+nu...@gmail.com> wrote: > 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.har...@gmail.com> > wrote: > >> On Fri, Jun 29, 2018 at 8:21 PM, Maxwell Aifer <mai...@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@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
