Can the dependency of FFTW be replaced by AbstractFFTs?

[heliosdrm]

FFT.jl is a particular implementation of AbstractFFTs.jl, with a few exensions documented in https://juliamath.github.io/FFTW.jl/stable/fft/
But unless I have missed something, FourierTools does not use any of those functions.

So perhaps the dependency from FFTW might be dropped in favor of AbstractFFTs, and let users choose their preferred implementation (FFTW if they want, but also maybe FastTransforms, or RustFFT, for instance).

This might be arguably breaking, since users should install any of those implementations explicitly in order to use this package (in the fashion of FileIO), although nothing of their code would change. The advantages are that FourierTools would be lighter and more flexible.

[roflmaostc]

Good remark.
What happens to all internal functions of FourierTools which call fft?

So to effectively use FourierTools, user always need to load a FFT backend. Right?

[RainerHeintzmann]

Maybe one can ship it with "batteries", i.e. FFTW included but it then uses the FourierToolsCore package where it exports also almost all it's functions?
This was we can maintain compatibility.

[roflmaostc]

Yeah we could but it would be some extra work.

So not sure if it's worth it.

Are the other mentioned packages in any way competitive with FFTW.jl already? So is it really of practical need?

[heliosdrm]

FFTW.jl has the drawback of relying on a third party library with a GPL license, and in some specific situations might be a barrier to depend on it. FastTransforms is pure Julia, and RustFFT depends on a library licensed under Apache and MIT. RustFFT.jl also claims to be faster than FFTW.jl (see its README), although it is limited to one-dimensional variables.

[heliosdrm]

So to effectively use FourierTools, user always need to load a FFT backend. Right?

Yes. e.g. using FourierTools (or using FourierToolsCore as per @RainerHeintzmann's suggestion) would not work alone. It should be using FourierToolsCore, FFTW or similar.

[roflmaostc]

Yeah, or we would do two packages
FourierToolsCore
And
FourierTools

The latter would pull in FFTW.jl as default.

[heliosdrm]

FastTransforms is pure Julia

Sorry, this statement was wrong: FastTransforms is a wrapper to a C library (MIT licensed).

[RainerHeintzmann]

Are you sure that FFTW.jl is not free to use in Julia?
At least the package is MIT licenced.
https://github.com/JuliaMath/FFTW.jl/blob/master/LICENSE
That is not GPL.

[roflmaostc]

Tdlr; The Julia code of FFTW.jl is MIT but not underlying FFTW code.

See https://github.com/JuliaMath/FFTW.jl?tab=readme-ov-file#license

[heliosdrm]

I was going to prepare a PR to test how this proposed change would look like, and have realized that it is not totally straightforward, because there are a few functions (plan_conv plus others in czt.jl) that do depend on some constants defined in FFTW.

[RainerHeintzmann]

... and possibly fftshift? Or is that part of the general framework?

[roflmaostc]

This is covered by AbstractFFTs.