Error with FFTW and generic FFT transforms

[astrozot]

I understand AppleAccelerate can only deal with power-of-two FFT transforms. However, I would not expect to see this error message, as FFTW should just use its standard (general) code:

julia> import FFTW, AppleAccelerate

julia> matrix = rand(1024, 1024);

julia> matrix = rand(1024, 1023);

julia> FFTW.plan_fft(matrix, flags=FFTW.MEASURE)
ERROR: ArgumentError: vDSP FFT requires power-of-2 dimensions (got size (1024, 1023)). Use FFTW.jl for arbitrary sizes.
Stacktrace:
 [1] _vdsp_unsupported(x::Matrix{ComplexF64})
   @ AppleAccelerateAbstractFFTsExt ~/.julia/packages/AppleAccelerate/mlJEJ/ext/AppleAccelerateAbstractFFTsExt.jl:43
 [2] #plan_fft#3
   @ ~/.julia/packages/AppleAccelerate/mlJEJ/ext/AppleAccelerateAbstractFFTsExt.jl:111 [inlined]
 [3] plan_fft
   @ ~/.julia/packages/AppleAccelerate/mlJEJ/ext/AppleAccelerateAbstractFFTsExt.jl:110 [inlined]
 [4] plan_fft
   @ ~/.julia/packages/AbstractFFTs/4iQz5/src/definitions.jl:215 [inlined]
 [5] #plan_fft#1
   @ ~/.julia/packages/AbstractFFTs/4iQz5/src/definitions.jl:68 [inlined]
 [6] top-level scope
   @ REPL[5]:1

Note that the error disappears if either matrix = rand(1024, 1024) or I do not import AppleAccelerate, as expected. I am reporting this here as, from what I understand, the issue is with the AppleAccelerate FFT extension, rather than with FFTW.js (which has no extensions actually).

[ViralBShah]

In general, I think AbstractFFTs is not set up for multiple simultaneous backends. So these two things must be ideally used separately.

I had claude build something in #142 but I'm not sure I like it. Thoughts?

[astrozot]

Thank you for taking the time to fix this. I am not an expert of AbstractFFTs, but indeed it looks like it can deal with simultaneous backends only if they operate on different types.

Given these constraints, I believe your implementation is the most reasonable one. My only concern is the use of invoke, which according to the documentation

is generally also slower–sometimes significantly so–than doing normal dispatch with a regular call.

The same documentation says

Be careful when using invoke for functions that you don't write. What definition is used for given argtypes is an implementation detail unless the function is explicitly states that calling with certain argtypes is a part of public API.

I don't think FFTW commits in any way regarding the exact type of the array parameter in plan_fft. It would be nice to avoid the use of invoke, but I believe this is not possible unless one refrains from defining plan_fft for standard arrays, and does it only for an internal type that "shadows" power-of-two 1D and 2D arrays. But that would be a breaking change, of course.