Proposed new feature or change:
Scipy switched its built-in FFT library from pocketfft to its successor ducc.fft in scipy/scipy#23436
Previous discussion in #17839. A lot of the obstacles no longer exist:
- Numpy switched to C++
pocketfft implementation, which makes it easier move to C++ ducc.fft
- The
ducc.fft files were changed to be dual-licensed under BSD-3-Clause OR GPL-2.0-or-later which should be compatible with Numpy
- If we switch to
ducc.fft we can also move multi-D FFT to ducc.fft instead of managing by Numpy
- Numpy doesn't have a vendoring script like SciPy. A submodule will import too many files from the
ducc repo. Can we check in the vendored files manually?
- Can Scipy depends on Numpy FFT and get rid of it's own
ducc.fft dependency?
I have a working local prototype, want to know how well this will be received before I proceed with a PR.
cc @mreineck
Proposed new feature or change:
Scipy switched its built-in FFT library from
pocketfftto its successorducc.fftin scipy/scipy#23436Previous discussion in #17839. A lot of the obstacles no longer exist:
pocketfftimplementation, which makes it easier move to C++ducc.fftducc.fftfiles were changed to be dual-licensed underBSD-3-Clause OR GPL-2.0-or-laterwhich should be compatible with Numpyducc.fftwe can also move multi-D FFT toducc.fftinstead of managing by Numpyduccrepo. Can we check in the vendored files manually?ducc.fftdependency?I have a working local prototype, want to know how well this will be received before I proceed with a PR.
cc @mreineck