> if a single program uses both np.polyval() and np.polynomail.Polynomial, it seems bound to cause unnecessary confusion.
Yes, I would recommend definitely not doing that! > I still think it would make more sense for np.polyval() to use conventional indexing Unfortunately, it's too late for "making sense" to factor into the design. `polyval` is being used in the wild, so we're stuck with it behaving the way it does. At best, we can deprecate it and start telling people to move from `np.polyval` over to `np.polynomial.polynomial.polyval`. Perhaps we need to make this namespace less cumbersome in order for that to be a reasonable option. I also wonder if we want a more lightweight polynomial object without the extra domain and range information, which seem like they make `Polynomial` a more questionable drop-in replacement for `poly1d`. Eric On Sat, 30 Jun 2018 at 09:14 Maxwell Aifer <mai...@haverford.edu> wrote: > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
