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 writes:
> 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
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: m...@astro.utoronto.ca
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
