See also #17801

Now that we allow C++ judiciously, there is a C++ version of PocketFFT that supports float, double and long double. I think that ought to be relatively straightforward to drop in place of our C PocketFFT implementation. If it's as simple as that, I'd say that crosses the threshold for me in favor of adding it to numpy (as opposed to continue to point people to use scipy.fft for a more full-featured implementation).

Yeah, this may have to be a silent API change, which is why I opened this: It may be good to do in a 2.0 release.

Implementing it could be started now, if we are unsure about it just disabling the promotion to double, that could be hidden behind NPY_NUMPY2_BEHAVIOR=1.

(I am not convinced that we absolutely cannot do it in a 1.x release, but I guess it may be an easier decision...)

Just N.B. since long double was mentioned: there is also talk about trying to get away with dropping long-double support. Unfortunately, many platforms have poor long-double support even though it is C99 (and a decent number just use double which is C99 conform of course)...

I think it would be fine in a 1.x release, but as you note, either way we could implement it now.

I would be very happy about this kind of change, since it brings the implementation in sync with scipy. In the long run scipy may even be able to drop its own copy of the C++ sources and call into numpy instead, correct? That could certainly help reduce binary sizes.

FYI CuPy already supports single-precision FFT and it's one of documented deviations from NumPy:
https://docs.cupy.dev/en/stable/reference/fft.html#code-compatibility-features

I think this should be implemented now, correct? (#25711)