split package

[stevengj]

The point of the dft.jl stuff is that you can plug in non-FFTW implementations (e.g. a pure-Julia FFT, FFTPACK, whatever) and it will still work with the same interface. So, it really needs to be split into a separate package.

My suggestion would be that there be a separate package (maybe "AbstractFFTs"?) that contains dft.jl. Then any package that provides FFT functionality would use this package.

Similarly the dsp stuff should probably be in a separate package.

[ararslan]

Regarding DSP, my plan was to move those functions to JuliaDSP/DSP.jl. They're the only Base functions which use FFTs, so for the sake of moving everything at once I figured it would be easiest to put them here temporarily, since DSP.jl would then require a dependency on this package.

I assume the same could be done for DFT: move to a separate package once all Fourier transform functionality has been excised from Base. Does that seem reasonable?

[stevengj]

That seems fine, but in the case of AbstractFFTs we can split it off earlier. That will also make it easier to start experimenting with pure-Julia FFTs.

[ararslan]

I have a bare-bones AbstractFFTs package but I haven't pushed it yet. Not sure what the tests should be, since AFAICT the existing Base tests are specific to the FFTW implementation of these definitions.

[ararslan]

Okay, pushed here: https://github.com/JuliaMath/AbstractFFTs.jl. No tests yet though.

[stevengj]

Thanks, this issue can be closed once FFTW.jl switches to requiring AbstractFFTs.jl