Make Python front end to the C math module
Currently the math module is written in C, not Python. This greatly increases the barrier to contributions to math. I suggest that we treat the existing math module as an accelerator module: - rename math.so to _math.so; (or whatever platform-specific name it uses) - add math.py with something like the following content: from _math import * and we're done! That will make it easier for people to contribute pure Python functions in the future. Currently all math functions, regardless of how trivial or difficult, must be written in C. With this change, they can be written in Python, and only written in C if necessary. For the avoidance of doubt, there is NO requirement for pure-Python implementations of the existing math functions, or even future ones. Future functions can go straight into the C implementation is desired. This is to allow future functions the opportunity to be written in Python. -- Steve
On 19 June 2016 at 16:02, Steven D'Aprano <steve@pearwood.info> wrote:
Is there any reason to do this in advance of an actual requirement for it? It seems to me that doing this when someone proposes a Python-coded math function would be fine. Or do you think that the fact that math is coded in C is stopping people even suggesting additions, because they believe they'd need to be able to write them in C? Paul
On Sun, Jun 19, 2016 at 06:04:47PM +0100, Paul Moore wrote:
Now that you mention it, I do have an actual requirement: http://bugs.python.org/issue27353
Its hard to say whether its stopping people from *proposing* new functionality, since talk is cheap. But its certainly a barrier to having them propose actual patches, since they must be written in C. To anticipate a likely objection, that math was originally conceived as a platform-specific thin wrapper around the C math library, I think that's well and truly past: - math is not limited to the C89 math library; - but nor does it contain all of the C99 math library (there's quite a bit missing); - and it includes functions not found in either C89 or C99. Python tries to smooth out platform specific differences regarding float, e.g. float('nan') works on all platforms, not just POSIX (Windows used to require '1.#IND'). I think it is fair to say that math will be closely aligned to your platform's C math library, but it is not restricted to that. I think the current documentation is clear: CPython implementation detail: The math module consists MOSTLY of thin wrappers around the platform C math library functions. [emphasis added] https://docs.python.org/3/library/math.html#constants -- Steve
I see your point, but I'm skeptical that it'll make much of a difference, and I do see a cost: "import math" would become a little slower and require a little more memory. If your n'th root function is a classic floating point algorithm, surely there's someone who can help you translate it into C (just ask), but just as surely there's probably already some public-domain C code you can copy. (Is it this? https://en.wikipedia.org/wiki/Nth_root#nth_root_algorithm) I think the math module ought to stay close to a libm wrapper in spirit (if not in implementation) because I don't really think that it ought to open itself up to all of mathematics -- there's simply too much of that. I do think a more accurate n'th root algorithm makes a fine addition, but I don't think such additions are common enough to try to encourage contributions. -- --Guido van Rossum (python.org/~guido)
Sent from my iPhone
Is there any reason to do this in advance of an actual requirement for it?
This was brought up last year when we added the isclose() function. In fact Victor even whipped up an implementation. Guido rejected the idea, and isclose() was implemented in C. -CHB
On 19 June 2016 at 16:02, Steven D'Aprano <steve@pearwood.info> wrote:
Is there any reason to do this in advance of an actual requirement for it? It seems to me that doing this when someone proposes a Python-coded math function would be fine. Or do you think that the fact that math is coded in C is stopping people even suggesting additions, because they believe they'd need to be able to write them in C? Paul
On Sun, Jun 19, 2016 at 06:04:47PM +0100, Paul Moore wrote:
Now that you mention it, I do have an actual requirement: http://bugs.python.org/issue27353
Its hard to say whether its stopping people from *proposing* new functionality, since talk is cheap. But its certainly a barrier to having them propose actual patches, since they must be written in C. To anticipate a likely objection, that math was originally conceived as a platform-specific thin wrapper around the C math library, I think that's well and truly past: - math is not limited to the C89 math library; - but nor does it contain all of the C99 math library (there's quite a bit missing); - and it includes functions not found in either C89 or C99. Python tries to smooth out platform specific differences regarding float, e.g. float('nan') works on all platforms, not just POSIX (Windows used to require '1.#IND'). I think it is fair to say that math will be closely aligned to your platform's C math library, but it is not restricted to that. I think the current documentation is clear: CPython implementation detail: The math module consists MOSTLY of thin wrappers around the platform C math library functions. [emphasis added] https://docs.python.org/3/library/math.html#constants -- Steve
I see your point, but I'm skeptical that it'll make much of a difference, and I do see a cost: "import math" would become a little slower and require a little more memory. If your n'th root function is a classic floating point algorithm, surely there's someone who can help you translate it into C (just ask), but just as surely there's probably already some public-domain C code you can copy. (Is it this? https://en.wikipedia.org/wiki/Nth_root#nth_root_algorithm) I think the math module ought to stay close to a libm wrapper in spirit (if not in implementation) because I don't really think that it ought to open itself up to all of mathematics -- there's simply too much of that. I do think a more accurate n'th root algorithm makes a fine addition, but I don't think such additions are common enough to try to encourage contributions. -- --Guido van Rossum (python.org/~guido)
Sent from my iPhone
Is there any reason to do this in advance of an actual requirement for it?
This was brought up last year when we added the isclose() function. In fact Victor even whipped up an implementation. Guido rejected the idea, and isclose() was implemented in C. -CHB
participants (5)
-
Chris Barker - NOAA Federal -
Guido van Rossum -
Paul Moore -
Steven D'Aprano -
tritium-list＠sdamon.com