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-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
