FFTA.plan_fft returns an FFTW plan if both FFTW and FFTA are used

[jtravs]

If I run

using FFTA
a = rand(ComplexF64, 128)
p = FFTA.plan_fft(a)
typeof(p)

I get

FFTA.FFTAPlan_cx{ComplexF64, 1}

but if I run

using FFTA, FFTW
a = rand(ComplexF64, 128)
p = FFTA.plan_fft(a)
typeof(p)

I get

FFTW.cFFTWPlan{ComplexF64, -1, false, 1, Tuple{Int64}}

This causes subtle bugs in my code, and presumably is not what is intended? Is this a misunderstanding on my part (on how Julia works) or can this be fixed somehow (in either FFTA, FFTW or AbstractFFTs)?

[dannys4]

yeah, this is the issue with using AbstractFFTs unfortunately: see, e.g., JuliaMath/AbstractFFTs.jl#32

I'm not sure personally how to circumvent this from a language design aspect, but it would be nice to have something similar to, e.g., the Backend ideas from AbstractDifferentiation.jl.

I'll mock something similar up so that you can switch between them.

[jtravs]

Thanks, I was coming to the same conclusion.

One easy workaround would be to make the plan_fft functions in FFTA directly call some other internal _plan_fft function. So that in these odd cases where I want specifically to get an FFTA plan I can call that internal function. Would you accept a PR that does something like that? A proper backend plan would be better, but the fix I suggest here is easy and costless (I think).

E.g. replace line 23 in plan.jl with something along the lines of:

function AbstractFFTs.plan_fft(x::AbstractArray{T}, region; kwargs...)::FFTAPlan_cx{T} where {T <: Complex}
    _plan_fft(x, region, kwargs...)
end

function _plan_fft(x::AbstractArray{T}, region; kwargs...)
    N = length(region)
    @assert N <= 2 "Only supports vectors and matrices"
    if N == 1
        g = CallGraph{T}(size(x,region[]))
        pinv = FFTAInvPlan{T,N}()
        return FFTAPlan_cx{T,N}((g,), region, FFT_FORWARD, pinv)
    else
        sort!(region)
        g1 = CallGraph{T}(size(x,region[1]))
        g2 = CallGraph{T}(size(x,region[2]))
        pinv = FFTAInvPlan{T,N}()
        return FFTAPlan_cx{T,N}((g1,g2), region, FFT_FORWARD, pinv)
    end
end

Obviosuly, the naming could be different.

[dannys4]

yeah that was my idea of a placeholder fix. I'd have to do something about ifft, rfft, irfft, and bfft. Also, to circumvent problems with multiple imports, I'd probably stray toward the side of caution and name it something like __FFTA_plan_fft. This is a little overkill tbh, but it would help avoid any possible issues in the future (and if the purpose is to disambiguate from other packages, better to stray on this side of cautious).