Repository navigation
Add 'half turns' functions (cospi et al) to math module following C23 & IEEE754-2019 #150534
Description
Feature or enhancement
Proposal:
C23 standardized multiple new trig functions in <math.h> that operate on units of “half turns”. These functions are recommended by IEEE754-2019. I propose adding these functions to CPython.
These function can be both more accurate and more performant than the traditional functions which take radian arguments, because inexact range reduction (e.g., modulo 2π) can be replaced by exact calculations (e.g., fmod(x, 2)) that never require excess precision.
Modern Linux systems such as Debian Trixie using glibc 2.41 include an implementation of all these C23 functions (regardless of whether building in C23 mode).
For instance, consider calculating the sine of 500π or 500 half-turns. The result is exactly zero with a proper math.sinpi implementation but nonzero with the traditional math.sin function, because 500π is not an exact FP number:
>>> math.sinpi(500), math.sin(math.pi*500)
(0.0, -1.6070832296378168e-13)For platforms which do not directly support these functions, for instance because they do not support the C23 standard or do not provide the functions when not building in C23 mode, implementations similar to the existing internal function mathmodule.c function m_sinpi can be used. These perform range reduction with fmod & special value checking before delegating to a platform radians-based routine (e.g., m_sinpi → sin() or cos()) with necessary scaling by a factor of π.
I have prototyped this addition. You can view it on github: https://github.com/python/cpython/compare/main...jepler:cpython:c23-math-pifuns?expand=1#diff
This branch includes new tests & documentation for the new functions.
Has this already been discussed elsewhere?
I have already discussed this feature proposal on Discourse
Links to previous discussion of this feature:
https://discuss.python.org/t/add-half-turns-functions-cospi-et-al-to-math-module/107550 [no replies yet]
Activity
picnixz commentedon May 27, 2026
jepler commentedon May 27, 2026
That was quick. Thank you for your kind consideration.
Mariatta commentedon May 27, 2026
Mariatta commentedon May 27, 2026
Reopening, until at least the Discourse thread gain traction or consensus. It is too early to decide because the Discourse thread was just opened on the same day as this issue.
picnixz commentedon May 27, 2026
We already had a discussion on C99 functions that took ages to be included. We honestly do not want to include C23 functions if even C11 are not yet considered.
And we usually close issues and only reope them once DPO has gained traction. Otherwise we have two places where discussions take place instead of one.
So please, let DPO be the place where consensus is built and GH issues be for actionable issues.
I deliberately left out some C99 functions out because even numpy did not include them.
picnixz commentedon May 27, 2026
cc @rhettinger @skirpichev and Mark who I can never tag
If we are to consider C23 functions I would rather have something for including C11 functions first, including configure options so as to ease builds.
And I am against reimplementing them for platforms that do not support it because math is not meant to be a general purpose library. Leave it to numpy or others.
jepler commentedon May 28, 2026
Note that though these functions are standardized in C23, there is no requirement of a C23 runtime because my branch provides implementations of the functions, similar to
m_sinpialready existing in the CPython source code and used internally.mathmodule.c already has at least
m_tgamma,m_lgamma,m_log1p,m_log2andm_remainderimplementing standard math functions where there is insufficient platform support. Have these been maintenance burdens?I did find the previous discussion of missing C99 functions in math here: #135853
I have read the thread's initial comment & skimmed the remainder. My main question is whether it is numpy or CPython who "takes the lead" in adding new mathematical functions. Must it consistently be one or the other, or have both sides sometimes innovated in including a function first?
I also found where
m_erfandm_erfccould be removed because C runtime implementations improved sufficiently: https://github.com/python/cpython/pull/101679/changes (the title refers to C11 but my reference suggests erf/erfc are C99, andf/lsuffixed versions are C11)Finally, another question about norms -- is this the type of discussion that should have been taking place on DPO instead of an issue? Knowing the correct venue for a conversation has been a pain-point for me here.
skirpichev commentedon May 28, 2026
Did Mark asked not to ping him? If not, lets ask - his opinion will be valuable.
JFR: #135853
Hmm, I don't remember that C11 added something. Can you be more specific here?
You could open PR against own fork. In such case you could remove the branch later without losing of the work (and breaking links).
BTW, I think you need better testing, like for other functions with custom implementations. See
Lib/test/mathdata/math_testcases.txt.In past, the math functions were implemented on all platforms. Lets not break this.
The proposal looks to be motivated by the standard, not real application. This is a weak point for me. We don't require yet C23-compatible compiler to build CPython and can't rely on presence of proposed functions.
JFR: https://discuss.scientific-python.org/t/1193/
mpmath has sinpi/cospi, but nothing else. Given that we already have private sinpi, I think it's fine if we expose this function accompanied with cospi (constructed from sinpi code).
terryjreedy commentedon May 28, 2026
I replied on discuss with the annoying fact the even sin(math.pi) is not 0, and +1, pending reasons not to add. 12 hearts now, 10 hours after posting.
@jepler We are in transition to requiring dpo discussion for sufficiently non-trivial new features. I know, a bit fuzzy. Thank you for your first post there. Next time, start there. A core dev may eventually open or suggest issue and PR.
@skirpichev mpmath.org doc omits doc for sinpi and cospi. Search AI summary suggests mpmath.sinpi(x) =
sin(pi * x) if x != int(x) else 0(or sin(pi * (x - int(x)) for positive x?) which is close to or maybe equal to the proposal. Yes, expose it.skirpichev commentedon May 28, 2026
It doesn't omit it, just exposes stub docs due to my typo. Thanks for the bug, now fixed:
https://mpmath.readthedocs.io/en/latest/functions/trigonometric.html#trigonometric-functions-with-modified-argument
rhettinger commentedon May 28, 2026
I'm not keen on bringing in every little thing from newer C standards. We did that with the
decimalmodule and ended-up with some unused junk.However, I'm +1 on this particular class of functions which solve a recurring annoyance with the existing trig functions. Had this tooling been available, I would had used it on more than one occasion. It is common to want to compute
sin(pi * x)and it would be nice to have had a version that is more accurate for small multiples, reliably handles large multiples, and is faster.Note the motivation for the
sinpias an improvement oversin(x * pi) is very similar to the motivation forlog10as an improvement overlog(x) / log(10)andlog(x, 10). Other functions likefma,expm1, andlog1palso provide speed and accuracy improvements over their algebraic equivalents.If our underlying C libraries don't directly support the function, we would need to roll our own as a backup (much like Mark did for
lgammaor I did forhypot).picnixz commentedon May 28, 2026
I'm sorry here! I actually got confused with C++17 which added functions in
<numeric>(not even in<cmath>).So, in light of the other's opinions, I believe it's ok to add sinpi/cospi. As for the custom implementation, yes it would increase maintainer's burden but if there are precedents, I'm fine with doing it here as well.
I read the standards and it appears that apart some other classifications functions + decimal-related ones (I think?), there are no other math functions so if we add them now there won't be a need to do more.
I suggest that we also include the arc* functions for completeness (I haven't tried, but I hope that it's not fp-equivalent to asin(x)/pi and that asinpi(n*pi) gives back$n$ ).
skirpichev commentedon May 28, 2026
IIUC, @rhettinger and @terryjreedy are for inclusion of all suggested functions.
That seems fine, if we are going for compatibility with the libm. After all, arc* functions seems to be trivial to implement. We have private sinpi, only non-trivial part is tanpi. I would worry here rather for pollution of the namespace.
IMO, this has 0 maintenance cost, assuming good review prior to merging.
No. C23 come with a lot of other changes in the math.h: exp10, exp2m1 and so on.
picnixz commentedon May 28, 2026
Oh I thought exp10() was already there, my bad. Well, we can leave that for later.
jepler commentedon May 28, 2026
I have created a pull request as suggested by @skirpichev
skirpichev commentedon May 29, 2026
I suggested to open a PR against your fork, not in the CPython repo. Though, I think now the proposal got enough support from core developers to open a real pull request.
gh-150534: Add C23 half-turn trigonometric *pi functions (GH-150555)
pythongh-150534: Add C23 half-turn trigonometric *pi functions (pytho…