BUG: Creating polynomials from existing polynomial instances incorrectly sets coefficients

In the polynomial package (np.polynomial), if one attempts to create a new polynomial instance from an existing instance, the entire original polynomial instance is stored in the coef attribute of the new polynomial instance (in an object array) without any error or warning being raised:

Reproducing code example:

>>> p = np.polynomial.Polynomial([1, 2, 3])
>>> p # expected
Polynomial([1., 2., 3.], domain=[-1,  1], window=[-1,  1])
>>> p2 = np.polynomial.Polynomial(p)
>>> p2 # p2.coef is an object array containing p
Polynomial([Polynomial([1., 2., 3.], domain=[-1,  1], window=[-1,  1])],
      dtype=object, domain=[-1,  1], window=[-1,  1])

Some potential solutions come to mind to prevent this from happening:

1. Disallow creating new polynomial instances from existing polynomial instances. This may break backwards compatibility
2. Construct the new polynomial instance from the state (i.e. coef, domain and window attributes) of the original polynomial.

Numpy/Python version information:

Python version: 3.8.2 NumPy version: 1.18.3

[rossbar]

Thanks so much @WarrenWeckesser & @charris for your detailed insights. @WarrenWeckesser , you are indeed right that this (along with #16108 and the associated issues) are inspired by thinking about what is the best way to change attributes other than the coef on the polynomial instance (i.e. the domain, window, or a proposed symbol for instance).

The point about cast is well-taken - other methods such as convert are intended to handle changing these attributes as well. These methods are entirely sufficient, but IMO are a little tricky because of how overloaded (in the general sense) they are. For instance, the convert method can be used to change the domain or window of a polynomial (and apply the corresponding transformation to the coef), linearly map the coefs from the domain -> window (if they differ), or to change the kind of polynomial, e.g. converting a Chebyshev instance to a Hermite instance (again, accounting for changes in the coef do to the change in basis). All that said, the point made above about being explicit (p2 = Polynomial(p.coef, window=p.window, domain=p.domain) instead of p2 = Polynomial(p)) is a good one.

The proposal in this PR also draws from the way np.poly1d, which has isinstance checks in __init__ in order to handle creation of new instances both from array-likes and from poly1d instances; though perhaps the decision not to go that route with the polynomial package was intentional!

I think @WarrenWeckesser makes a strong case above for not modifying the constructor as a means for creating polynomial instances with different domain and window attributes, so I’m inclined to close this. Thanks again, all, for taking a close look at the proposal!

[rossbar]

Thanks for weighing in @anirudh2290 , those are good points. Re: multivariate polynomials, I agree that the docs for the polynomial package do no mention support for multivariable polynomials, though they don’t specifically discount them either (unlike np.poly1d from the “old” polynomial API, which has 1d in the name).

One thing to be careful of: the polyval that is in the main numpy namespace (i.e. np.polyval) is actually the polyval from the “old” polynomial module np.lib.polynomial. There is a polyval associated with the new polynomial package, i.e. np.polynomial.polynomial.polyval. In fact, after careful inspection, there are also 2d and 3d functions defined, e.g. np.polynomial.polynomial.polyval[2,3]d. However there is not currently any support for multivariable polynomials through the convenience classes, which are the preferred interface for the np.polynomial package. In other words, there is some support for evaluation of multivariable polynomial expressions, but it is not discoverable and has not been added to the preferred (class-based) interface.

If there are plans in the future to support multivariable polynomials with the convenience classes, then indeed some additional thought will be needed to define how the coefs will be stored and what the constructor and evaluation will look like. I don’t know what the plans are for adding support for multivariable polynomial expressions to the np.polynomial package - maybe @charris has some insight on that front.