Accommodate AbstractFFTs.jl#26 fftfreq etc.

[carstenbauer]

This PR accommodates JuliaMath/AbstractFFTs.jl#26.

The definitions for fftfreq, rfftfreq, as well as the Frequencies type has been moved to AbstractFFTs.jl. Hence these definitions aren't necessary in DSP.jl anymore.

All tests pass locally. They will fail here, since JuliaMath/AbstractFFTs.jl#26 hasn't been merged yet.

Do not merge before JuliaMath/AbstractFFTs.jl#26 has been merged!

[galenlynch]

Could you also:

1. Add a deprecation for these functions, pointing users to AbstractFFTs
2. Remove tests in test/util.jl
3. Remove the documentation fromdocs/src/util.jl

[ssfrr]

Agreed there should be deprecation warnings here, though I don't think they should guide the user to use AbstractFFTs. As far as I understand the FFT usage, users shouldn't generally import AbstractFFTs directly. Most folks should import FFTW, which re-exports all functions exported from AbstractFFTs. CuArrays is another provider of FFT implementations, which doesn't currently use @reexport to re-export all the symbols but I think it should.

I guess people writing generic code that takes in arrays of unknown types would use AbstractFFTs and then rely on the user to have the correct implementations loaded for whatever arrays they're using?

Perhaps @ararslan or @stevengj can clarify what the expectation is for how the FFT packages are supposed to be used?

[ararslan]

From the AbstractFFTs README:

This package is mainly not intended to be used directly.

So I agree that deprecations shouldn't point directly to AbstractFFTs.

[carstenbauer]

@galenlynch I implemented you suggestions. Regarding the deprecation I just @deprecated functions to equivalents reexported by FFTW for now.

[galenlynch]

@crstnbr could you please implement @martinholters suggestions so we can merge this once a new tagged version on AbstractFFTs.jl is available?

[carstenbauer]

@galenlynch I'm currently on vacation. Will try to get back to this next week!

[carstenbauer]

Alright, tests pass locally (with AbstractFFTs#master and FFTW#master).

[carstenbauer]

Now that JuliaMath/AbstractFFTs.jl#26 has been merged and a new release has been tagged (https://github.com/JuliaMath/AbstractFFTs.jl/releases/tag/v0.5.0) this should be merged.

Notice https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708/135,

[ararslan]

This should set AbstractFFTs = "0.5" in the Project.toml [compat] section.

[carstenbauer]

This should set AbstractFFTs = "0.5" in the Project.toml [compat] section.

Why? DSP doesnt have AbstractFFTs as a direct dependency. So this shouldn't be necessary, right? Instead I believe we should set the FFTW compat, which I do in #321.

[ararslan]

We just need to make sure that DSP can't get AbstractFFTs < 0.5.

[ararslan]

Something like JuliaMath/FFTW.jl#124 will be necessary, I think. (cf #321 (comment))

[ararslan]

Suggested change

import FFTW: Frequencies, fftfreq, rfftfreq

I believe this isn't necessary, since there's a using FFTW and FFTW reexports the symbols from AbstractFFTs. Same with the import from DSP in the tests.

[ararslan]

I put this and #321 together with an adjustment to the FFTW bound and a version bump in #322 with Carsten's authorship preserved. Thanks so much for your work on this, @crstnbr!