Use pypocketfft as FFT backend?

Numpy 1.17 has adopted the C version of pocketfft (https://gitlab.mpcdf.mpg.de/mtr/pocketfft) as their FFT implementation. Since then I have been working on the pocketfft code, converted it to C++ and added a Python wrapper.

The new library (https://gitlab.mpcdf.mpg.de/mtr/pypocketfft)

• supports complex and half-complex transforms, also Hartley transforms
• supports float, double and long double precision
• supports multi-dimensional FFTs
• uses CPU vector instructions for ndim>1 (i.e. it computes several 1D FFTs dimultaneously).
• uses the Bluestein algorithm for FFTs with large prime factors

Performance is significantly better than FFTPACK’s, accuracy as well. For benchmarks and dicussion see https://github.com/numpy/numpy/pull/11888 and recent comments in https://github.com/numpy/numpy/issues/11885. I have also added an interface which is very similar to scipy.fftpack.

Potential problems for adaptation:

• written in C++, requires a C++11 compiler and pybind11
• cosine/sine transforms are missing, and I probaly won’t have the time ti implement them. They would have to be added on top of the existing machinery.

Would this be of interest for Scipy?

[rgommers]

In case it wasn’t clear: I don’t think there should be a default and backends; I think there should be a default backend. i.e. the default fft library would implement the same interface that a 3rd party backend would.

Yes that makes sense. I think we’re saying the same thing in different words:)

@larsoner do you mean as well as scipy.fftpack or instead of?

I’m pretty sure “instead of”.

I thought that part of the idea of adding backends was that existing code using scipy.fftpack could benefit.

For most existing code it’s an extra one-liner change (import fft instead of fftpack). Also, it cleans up the ugly fftpack name, which never made too much sense

[larsoner]

I’m starting to think “instead of” (i.e., keep scipy.fftpack just for backward compatibility and focus this new effort on a new scipy.fft) might be nicer in the long term from a maintainability and usability/naming/user expectation perspective.