[Numpy-discussion] Polynomial evaluation inconsistencies

[Charles R Harris]

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>