On Sat, Jun 30, 2018 at 12:09 PM, Eric Wieser <wieser.eric+nu...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
