
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:
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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: mhvk@astro.utoronto.ca