On Fri, Jun 12, 2026 at 2:33 PM Nathan via NumPy-Discussion < [email protected]> 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 <[email protected]> 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-functions-to-special/1193. >> 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-L396 >> . >> >> 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 <[email protected]> wrote: >> >> I like the idea ! >> >> On Mon, 08 Jun 2026 08:59:24 -0500 >> "Jeff Epler" <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3//lists/numpy-discussion.python.org >> Member address: [email protected] >> >> _______________________________________________ >> NumPy-Discussion mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3//lists/numpy-discussion.python.org >> >> Member address: [email protected] >> >> >> _______________________________________________ >> NumPy-Discussion mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3//lists/numpy-discussion.python.org >> Member address: [email protected] >> > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] >
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
