[Numpy-discussion] Polynomial evaluation inconsistencies
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>
> > 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 : from numpy.polynomial import Polynomial as P
In : p = P([1, 2, 3], domain=(0,2))
In : p(0)
In : p.convert()
Out: Polynomial([ 2., -4., 3.], domain=[-1., 1.], window=[-1., 1.])
In : p.convert()(0)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion