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 < > [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.
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 <[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] _______________________________________________ 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]
