Adding `P.coef_natural` property to polynomials
![](https://secure.gravatar.com/avatar/225f9598f1d35baa94f2e1cc5bee6103.jpg?s=120&d=mm&r=g)
Hello, I would like to add a property `P.coef_natural` to polynomials. Would you accept it? Reason: Most people who had ground courses on polynomials expect `P.coef` to return the natural coefficients. They face a huge confusion because this is not the case and because the `coef` attribute is not linked to a documentation. Moreover, the documentation of the class does not explain the situation clearly either. Solution: I propose to add a property `P.coef_natural` to polynomials, with the suitable documentation. In this situation, basic users will have an easier path to understanding. Proposed implementation: https://github.com/numpy/numpy/pull/27232/files Further possible options: - Add a property `P.coef_internal` that would copy `P.coef` and provide documentation. - Hide `P.coef` into `P._coef` and leave only `P.coef_natural` and `P.coef_internal` visible. (1) Can you comment and tell if you accept this? (2) Any opinion about whether the options should be implemented? The main idea is that we should not require basic users to be specialists of the subtleties of the module. Olivier
![](https://secure.gravatar.com/avatar/73e482f0af57b624af58ddc78fe9b128.jpg?s=120&d=mm&r=g)
Hi Olivier, Thanks for bringing this up here! As stated by Chuck in the issue leading to the PR, https://github.com/numpy/numpy/issues/26401 there are real risks with using natural coefficients for polynomials: we really want to move people away from situations in which large cancellation errors are going to cause bad results. But more importantly, as I noted there, "natural" coefficients make very little if any sense for some of the other polynomial subclasses, such as Chebyshev -- for those, there's nothing natural about them! Hence, I think it actually better to stick with somewhat more elaborate solution that is currently possible, ``poly.convert().coef``. That said, I fully agree with you that the documentation could be better. A minimal change that would help already quite a bit is simply to hide the ``.coef`` attribute behind a ``property``, so that it can be given a proper docstring. More generally, the documentation could use an overhaul. In the end, I think documentation work is going to be much more impactful in this case. All the best, Marten oc-spam66--- via NumPy-Discussion <numpy-discussion@python.org> writes:
![](https://secure.gravatar.com/avatar/225f9598f1d35baa94f2e1cc5bee6103.jpg?s=120&d=mm&r=g)
I can summarize the different possibilities/proposals: (A) Create new properties: add a `P.coef_natural` property, with a suitable documentation ; maybe also add a `P.coef_internal` property. There would be no change to the existing code (only addition of properties). (B) Change `P.coef` attribute into a property, with a suitable documentation. Hide `P.coef` attribute into `P._coef` (change existing code). Do not create more properties (unlike A). - About (A), I don't think that adding `P.coef_natural` would add a risk. - About (B), it may be appreciated that the API does not change (does not occupy more namespace) - Both (A) and (B) would help basic users to get out of the `P.coef` attribute confusion. Side remark (not important):
"natural" coefficients make very little if any sense for some of the other polynomial subclasses, such as Chebyshev -- for those, there's nothing natural about them! Are you sure? Can they not be the weights at different order of approximation of a solution?
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Sun, Sep 1, 2024 at 6:48 AM Rakshit Singh <rakshitsingh421@gmail.com> wrote:
Chebyshev polynomials have two important properties over the interval [-1, 1]: 1. They are equiripple, consequently the coefficients of high power fits are a good approximation of the maximum error if the series is truncated at that point, i.e., they provide something close to an min-max fit. 2. High power fits are practical because the polynomials are more independent (in the L2 norm). The design matrix is generally well-conditioned. Chebyshev polynomials are quite wonderful, but only if the domain of the data is in the range [-1, 1]. Similar arguments apply to Legendre polynomials, but in that case the coefficients approximate the L2 error when the series is truncated and properly normalized. In both cases, the coefficients are a good guide to the power needed to fit the underlying data with minimum influence from noise. Chuck
![](https://secure.gravatar.com/avatar/225f9598f1d35baa94f2e1cc5bee6103.jpg?s=120&d=mm&r=g)
What do you mean by "changing the API"? - Case (A): Adding a property `P.coef_natural` is not a change IMO, it is an addition. - Case (B): Do you consider that changing `P.coef` from an attribute to a property is a change in the API ? It is transparent IMO.
![](https://secure.gravatar.com/avatar/73e482f0af57b624af58ddc78fe9b128.jpg?s=120&d=mm&r=g)
Hi Olivier, Thanks for bringing this up here! As stated by Chuck in the issue leading to the PR, https://github.com/numpy/numpy/issues/26401 there are real risks with using natural coefficients for polynomials: we really want to move people away from situations in which large cancellation errors are going to cause bad results. But more importantly, as I noted there, "natural" coefficients make very little if any sense for some of the other polynomial subclasses, such as Chebyshev -- for those, there's nothing natural about them! Hence, I think it actually better to stick with somewhat more elaborate solution that is currently possible, ``poly.convert().coef``. That said, I fully agree with you that the documentation could be better. A minimal change that would help already quite a bit is simply to hide the ``.coef`` attribute behind a ``property``, so that it can be given a proper docstring. More generally, the documentation could use an overhaul. In the end, I think documentation work is going to be much more impactful in this case. All the best, Marten oc-spam66--- via NumPy-Discussion <numpy-discussion@python.org> writes:
![](https://secure.gravatar.com/avatar/225f9598f1d35baa94f2e1cc5bee6103.jpg?s=120&d=mm&r=g)
I can summarize the different possibilities/proposals: (A) Create new properties: add a `P.coef_natural` property, with a suitable documentation ; maybe also add a `P.coef_internal` property. There would be no change to the existing code (only addition of properties). (B) Change `P.coef` attribute into a property, with a suitable documentation. Hide `P.coef` attribute into `P._coef` (change existing code). Do not create more properties (unlike A). - About (A), I don't think that adding `P.coef_natural` would add a risk. - About (B), it may be appreciated that the API does not change (does not occupy more namespace) - Both (A) and (B) would help basic users to get out of the `P.coef` attribute confusion. Side remark (not important):
"natural" coefficients make very little if any sense for some of the other polynomial subclasses, such as Chebyshev -- for those, there's nothing natural about them! Are you sure? Can they not be the weights at different order of approximation of a solution?
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Sun, Sep 1, 2024 at 6:48 AM Rakshit Singh <rakshitsingh421@gmail.com> wrote:
Chebyshev polynomials have two important properties over the interval [-1, 1]: 1. They are equiripple, consequently the coefficients of high power fits are a good approximation of the maximum error if the series is truncated at that point, i.e., they provide something close to an min-max fit. 2. High power fits are practical because the polynomials are more independent (in the L2 norm). The design matrix is generally well-conditioned. Chebyshev polynomials are quite wonderful, but only if the domain of the data is in the range [-1, 1]. Similar arguments apply to Legendre polynomials, but in that case the coefficients approximate the L2 error when the series is truncated and properly normalized. In both cases, the coefficients are a good guide to the power needed to fit the underlying data with minimum influence from noise. Chuck
![](https://secure.gravatar.com/avatar/225f9598f1d35baa94f2e1cc5bee6103.jpg?s=120&d=mm&r=g)
What do you mean by "changing the API"? - Case (A): Adding a property `P.coef_natural` is not a change IMO, it is an addition. - Case (B): Do you consider that changing `P.coef` from an attribute to a property is a change in the API ? It is transparent IMO.
participants (4)
-
Charles R Harris
-
Marten van Kerkwijk
-
oc-spam66@laposte.net
-
Rakshit Singh