You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to implement a very simple FFT interface, mimicking the numpy.fft default behavior. This means that we want the following matrix of functions:
fft for standard complex to complex transforms, rfft for real FFTs (real signal) and hfft for Hermitian FFTs (real Fourier spectrum);
an inverse for each operation, prepending an i, e.g. ifft;
a 1D (default), 2D, 3D and nD version of each function, the latter three indicated by appending 2, 3 or n, e.g. irfft3.
That's a total of 24 functions.
Additionally, we want to support single, double and long double precision arrays. This can be implemented through template specializations. The total amount of implemented functions would then be 72.
Also part of this interface would be broadcasting over multiple array dimensions, if the dimension of the function is smaller than that of the array itself; see #4.
One issue to decide on is how to deal with FFTWs behavior of destroying input for complex to real transforms (see FFTW_DESTROY_INPUT).
For multi-dimensional transforms it's not possible to use FFTW_PRESERVE_INPUT, so it might be more consistent to set it to FFTW_DESTROY_INPUT for 1D transforms as well.
However, this will break numpy.fft compatibility. It may be good to print a warning message to make this clear.
FFTW offers specialized functions for ranks 1, 2 and 3 and a general function for n-dimensional transforms. However, we should benchmark whether the 1-3 dimensional special functions are actually faster than the n-dimensional one. If not, we can just use one implementation function for all ranks, with simple wrappers for the 1, 2 and 3 dimensional cases. This would reduce the number of implemented functions from 72 to 18, plus 54 simple wrapper functions. See issue #13.
Activity
egpbos commentedon Oct 3, 2017
One issue to decide on is how to deal with FFTWs behavior of destroying input for complex to real transforms (see FFTW_DESTROY_INPUT).
For multi-dimensional transforms it's not possible to use FFTW_PRESERVE_INPUT, so it might be more consistent to set it to FFTW_DESTROY_INPUT for 1D transforms as well.
However, this will break numpy.fft compatibility. It may be good to print a warning message to make this clear.
egpbos commentedon Oct 3, 2017
FFTW offers specialized functions for ranks 1, 2 and 3 and a general function for n-dimensional transforms. However, we should benchmark whether the 1-3 dimensional special functions are actually faster than the n-dimensional one. If not, we can just use one implementation function for all ranks, with simple wrappers for the 1, 2 and 3 dimensional cases. This would reduce the number of implemented functions from 72 to 18, plus 54 simple wrapper functions. See issue #13.
egpbos commentedon Oct 3, 2017
Edited top comment, adding multiple precision functions.
Added tests for basic numpy.fft-like interface (#6)
First version of basic interface for xarray (#6)
egpbos commentedon Oct 10, 2017
The templates from commit 133f1be should probably be inline.
Made templates inline, does not change performance
Real FFTs working on xarrays for all dimensions (#6)
egpbos commentedon Oct 16, 2017
Regarding the destroy input comment above: I opted to go for destructive functions. This should be added to the documentation (#12).
Fixed 2D, 3D and nD xarray FFT tests
HFFT family implemented for xarray (#6)