[Numpy-discussion] Polynomial evaluation inconsistencies (original) (raw)

Charles R Harris charlesr.harris at gmail.com
Sat Jun 30 14:30:18 EDT 2018

On Sat, Jun 30, 2018 at 12:09 PM, Eric Wieser <wieser.eric+numpy at gmail.com> wrote:

> 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.

The defaults for domain and window make it like a regular polynomial. For fitting, it does adjust the range, but the usual form can be recovered with p.convert() and will usually have more accurate coefficients due to using a better conditioned matrix during the fit.

In [1]: from numpy.polynomial import Polynomial as P

In [2]: p = P([1, 2, 3], domain=(0,2))

In [3]: p(0) Out[3]: 2.0

In [4]: p.convert() Out[4]: Polynomial([ 2., -4., 3.], domain=[-1., 1.], window=[-1., 1.])

In [5]: p.convert()(0) Out[5]: 2.0

Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180630/f3a630a2/attachment.html>

More information about the NumPy-Discussion mailing list