More generic FFT about fasttransforms.jl HOT 5 CLOSED

I'll make a pull request and then we can see.

from fasttransforms.jl.

Related: #34. Originally, I thought that someone from FFTW with connections to Julia might write native generic FFTs, but I suppose we can't wait forever.

from fasttransforms.jl.

Oops, I did not see the existing issue.

The generic FFT code works with other AbstractFloat types, but making them accessible for any AbstractFloat like I suggested above is not free of issues. For example, since dct is defined for Vectors in FastTransforms but for AbstractArrays (with any dimension) in FFTW, the definition of FastTransforms.jl is actually more specific. Hence, it ends up getting called, even when the argument has Float64 elements. Furthermore, the test suite yields StackOverflowErrors, presumably for a similar reason. For the time being, the code is here: https://github.com/daanhb/FastTransforms.jl/blob/genericfft/src/fftBigFloat.jl

from fasttransforms.jl.

The code now works and all tests pass, with some changes to the codeflow. I've renamed fft to generic_fft. The fft routines in AbstractFFTs.jl invoke plan_fft (and friends). We implement plan_fft with the same signature as in FFTW, but such that the methods of FFTW are more specific than ours when T is one of the fftwNumber types. We provide a fallback for any AbstractFloat. The dummy plans of FastTransforms subsequently call generic_fft (and friends).

So: fft (AbstractFFTs) -> plan_fft (FastTransforms) -> DummyFFTPlan.
The DummyFFTPlan calls generic_fft.

For Float64: fft (AbstractFFTs) -> plan_fft (FFTW) -> SomeFFTWPlan, much more efficient.

I've had to change the dummy plan for irfft to include the extra integer argument, which is the length of the original vector to which rfft was applied. I'll make a pull request.

from fasttransforms.jl.

Closed by #64

from fasttransforms.jl.