ENH: Add np.sinpi et al following CPython core, C23 & IEEE754-2019
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0. These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019). C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers." Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions). I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback. Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
I like the idea ! On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-.... There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L.... We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two. Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net <mailto:jepler@unpythonic.net>> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org <mailto:numpy-discussion@python.org> To unsubscribe send an email to numpy-discussion-leave@python.org <mailto:numpy-discussion-leave@python.org> https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: lucas.colley8@gmail.com <mailto:lucas.colley8@gmail.com>
How is it typically decided whether some array function goes in numpy or scipy? On Tue, Jun 9, 2026, at 11:08 AM, Lucas Colley via NumPy-Discussion wrote:
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-.... There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L....
We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two.
Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ 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: lucas.colley8@gmail.com
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: jepler@unpythonic.net
There is no hard-and-fast rule, besides that changing the NumPy API surface has a much larger blast radius than changing the SciPy API surface. Adding ufuncs to the NumPy API forces downstream projects that attempt to be compatible with the full NumPy API to add support. There’s the array API standard to consider: https://data-apis.org/array-api/latest/ I’m not saying to go to them and ask them to standardize it. That’s not how it’s supposed to work: things become standardized after gaining widespread adoption. That said, has this come up in any array API discussions? Also, do other array or tensor libraries implement it? Increasing interoperability and making it easier for the same Python function to be used regardless of the underlying array type is a core project goal. On Fri, Jun 12, 2026 at 6:25 AM Jeff Epler <jepler@unpythonic.net> wrote:
How is it typically decided whether some array function goes in numpy or scipy?
On Tue, Jun 9, 2026, at 11:08 AM, Lucas Colley via NumPy-Discussion wrote:
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-.... There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L... .
We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two.
Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ 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: lucas.colley8@gmail.com
_______________________________________________ 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: jepler@unpythonic.net
_______________________________________________ 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: nathan12343@gmail.com
On Fri, Jun 12, 2026 at 2:33 PM Nathan via NumPy-Discussion < numpy-discussion@python.org> wrote:
There is no hard-and-fast rule, besides that changing the NumPy API surface has a much larger blast radius than changing the SciPy API surface. Adding ufuncs to the NumPy API forces downstream projects that attempt to be compatible with the full NumPy API to add support.
There’s the array API standard to consider: https://data-apis.org/array-api/latest/
I’m not saying to go to them and ask them to standardize it. That’s not how it’s supposed to work: things become standardized after gaining widespread adoption.
That said, has this come up in any array API discussions?
It hasn't - and since no other array library in Python seems to have it, that's fairly premature to bring up I'd say.
Also, do other array or tensor libraries implement it? Increasing interoperability and making it easier for thesame Python function to be used regardless of the underlying array type is a core project goal.
C23, Fortran 2023, IEEE754-2019, Julia, Matlab and R all have it, which is pretty solid prior art. In addition to the RFC Lucas linked, there's a stalled open PR to add it to scipy.special that might be useful: https://github.com/scipy/scipy/pull/21398. I'll note that it also covers complex dtypes (as it should), and that C23 et al. are real-valued only. So NumPy wouldn't be able to count on `libm` support for many years, probably never, and it'd have to handle more dtypes than `scipy.special` (e.g., float16, longdouble). There's also the amount of functions: is it sinpi/cospi/tanpi, or also their inverses? And the SciPy PR has cotpi as well (not sure if that makes sense to add there, but almost certainly not to NumPy). Given all that, I'd be inclined to put it in `xsf` and `scipy.special`, supporting only float32/float64/complex64/complex128. The xsf implementation could then also support CuPy. Cheers, Ralf
On Fri, Jun 12, 2026 at 6:25 AM Jeff Epler <jepler@unpythonic.net> wrote:
How is it typically decided whether some array function goes in numpy or scipy?
On Tue, Jun 9, 2026, at 11:08 AM, Lucas Colley via NumPy-Discussion wrote:
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-.... There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L... .
We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two.
Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ 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: lucas.colley8@gmail.com
_______________________________________________ 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: jepler@unpythonic.net
_______________________________________________ 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: nathan12343@gmail.com
_______________________________________________ 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: ralf.gommers@googlemail.com
On Fri, 2026-06-12 at 21:31 +0200, Ralf Gommers via NumPy-Discussion wrote:
On Fri, Jun 12, 2026 at 2:33 PM Nathan via NumPy-Discussion < numpy-discussion@python.org> wrote:
There is no hard-and-fast rule, besides that changing the NumPy API surface has a much larger blast radius than changing the SciPy API surface. Adding ufuncs to the NumPy API forces downstream projects that attempt to be compatible with the full NumPy API to add support.
There’s the array API standard to consider: https://data-apis.org/array-api/latest/
I’m not saying to go to them and ask them to standardize it. That’s not how it’s supposed to work: things become standardized after gaining widespread adoption.
That said, has this come up in any array API discussions?
It hasn't - and since no other array library in Python seems to have it, that's fairly premature to bring up I'd say.
Also, do other array or tensor libraries implement it? Increasing interoperability and making it easier for thesame Python function to be used regardless of the underlying array type is a core project goal.
C23, Fortran 2023, IEEE754-2019, Julia, Matlab and R all have it, which is pretty solid prior art.
Yeah, it seems fine to me to implement in NumPy given that even Python has it now. The only thing we should consider is to see where the `min/max` shakes out on namespaces. Not saying that `sinpi` shouldn't be in the main namespace, it seems OK to me. But if we have a new namespace for things that you rarely strictly need but that are faster, more precise, or just convenient then we could consider using it. (This would rely on "See Also" for discoverability.) - Sebastian
In addition to the RFC Lucas linked, there's a stalled open PR to add it to scipy.special that might be useful: https://github.com/scipy/scipy/pull/21398. I'll note that it also covers complex dtypes (as it should), and that C23 et al. are real-valued only. So NumPy wouldn't be able to count on `libm` support for many years, probably never, and it'd have to handle more dtypes than `scipy.special` (e.g., float16, longdouble). There's also the amount of functions: is it sinpi/cospi/tanpi, or also their inverses? And the SciPy PR has cotpi as well (not sure if that makes sense to add there, but almost certainly not to NumPy). Given all that, I'd be inclined to put it in `xsf` and `scipy.special`, supporting only float32/float64/complex64/complex128. The xsf implementation could then also support CuPy.
Cheers, Ralf
On Fri, Jun 12, 2026 at 6:25 AM Jeff Epler <jepler@unpythonic.net> wrote:
How is it typically decided whether some array function goes in numpy or scipy?
On Tue, Jun 9, 2026, at 11:08 AM, Lucas Colley via NumPy- Discussion wrote:
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-... . There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L... .
We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two.
Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ 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: lucas.colley8@gmail.com
_______________________________________________ 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: jepler@unpythonic.net
_______________________________________________ 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: nathan12343@gmail.com
_______________________________________________ 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: ralf.gommers@googlemail.com
_______________________________________________ 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: sebastian@sipsolutions.net
sinpi etc. is also is also part of the Fortran 2023 standard. So, NumPy would seem more appropriate. On Fri, 12 Jun 2026 at 22:25, Jeff Epler <jepler@unpythonic.net <mailto:jepler@unpythonic.net>> wrote: __ How is it typically decided whether some array function goes in numpy or scipy? On Tue, Jun 9, 2026, at 11:08 AM, Lucas Colley via NumPy-Discussion wrote:
There was a proposal to add these to `scipy.special`: https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-... <https://discuss.scientific-python.org/t/rfc-add-sinpi-cospi-tanpi-and-cotpi-...>. There are existing implementations at https://github.com/scipy/xsf/blob/main/include/xsf/trig.h <https://github.com/scipy/xsf/blob/main/include/xsf/trig.h> , with `sinpi` and `cospi` exposed to SciPy (privately) at https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L... <https://github.com/scipy/scipy/blob/main/scipy/special/xsf_wrappers.h#L394-L...>.
We should probably decide whether these best belong in `numpy` or `scipy.special`, and only expose them in one of the two.
Cheers, Lucas
On 9 Jun 2026, at 16:23, Jerome Kieffer <Jerome.Kieffer@esrf.fr <mailto:Jerome.Kieffer@esrf.fr>> wrote:
I like the idea !
On Mon, 08 Jun 2026 08:59:24 -0500 "Jeff Epler" <jepler@unpythonic.net <mailto:jepler@unpythonic.net>> wrote:
In a recently merged PR (https://github.com/python/cpython/pull/150555 <https://github.com/python/cpython/pull/150555>), CPython has added a family of "*pi" functions to the math module, which take half-turn arguments instead of radians. One reason these functions are advantageous is that it's easy to provide the property that `sinpi(n/2)` is exact for all integers n, while `sin(pi*n)` is never exactly equal to the mathematical ideal except for n=0.
These functions are recommended by IEEE754-2019 and standardized in C23 Annex G. (note: I'm reading C23 draft revised 2023-01-24, not the final standard document; and I do not have IEEE754-2019).
C23 and CPython only added the real-valued versions of these functions, but C23 "future library directions" notes that identifiers like `csinpi` are "potentially reserved identifiers."
Since CPython only requires C11, CPython includes implementations of these functions for when the underling platform library does not provide it. These implementations work by performing special case handling & range reduction, followed by a call to the standard trig function with a scaled argument (in the case of forward functions) or scaling of the result (in the case of inverse/arc functions).
I am interested in doing the numpy implementation, however I have never done core numpy work before. If there is interest from the project, I would like to initially offer a PR containing a single function such as `sinpi` and then complete the others following numpy core developer feedback.
Thanks, Jeff PS I notice via the archives that there are occasional "New Contributors' Hour" meetings. Is the next one scheduled yet?
-- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ NumPy-Discussion mailing list --numpy-discussion@python.org <mailto:numpy-discussion@python.org> To unsubscribe send an email tonumpy-discussion-leave@python.org <mailto:numpy-discussion-leave@python.org> https://mail.python.org/mailman3//lists/numpy-discussion.python.org <https://mail.python.org/mailman3//lists/numpy-discussion.python.org> Member address:lucas.colley8@gmail.com <mailto:lucas.colley8@gmail.com>
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org <mailto:numpy-discussion@python.org> To unsubscribe send an email to numpy-discussion-leave@python.org <mailto:numpy-discussion-leave@python.org> https://mail.python.org/mailman3//lists/numpy-discussion.python.org <https://mail.python.org/mailman3//lists/numpy-discussion.python.org> Member address: jepler@unpythonic.net <mailto:jepler@unpythonic.net>
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org <mailto:numpy-discussion@python.org> To unsubscribe send an email to numpy-discussion-leave@python.org <mailto:numpy-discussion-leave@python.org> https://mail.python.org/mailman3//lists/numpy-discussion.python.org <https://mail.python.org/mailman3//lists/numpy-discussion.python.org> Member address: python@2sn.net <mailto:python@2sn.net> -- Are worried about the future? Do you have a fundamental understanding of the basic nature of time? No? Then, why worry?
participants (7)
-
Alexander Heger -
Jeff Epler -
Jerome Kieffer -
Lucas Colley -
Nathan -
Ralf Gommers -
Sebastian Berg