[SciPy-dev] Dropping djbfft ?

[David Cournapeau]

Robert Kern wrote:
>
> I'd drop FFTW and MKL support first before djbfft because they are not
> compatible with the scipy license.

Ok.

>  If we moved the dispatching up to Python and just let external
> packages register themselves, we can probably save ourselves a
> substantial number of headaches. By separating the backend
> implementations, each can actually be unit-tested instead of
> integration-tested, and no one has to face a combinatorial explosion.
Yes, that's exactly what I wanted to do (fftpack by default, always, and 
dynamically changing the backend if wanted). I am trying to define 
fftpack as a C header, and each backend as an implementation of this 
API. But since no backend implements the same things (fftpack aside), 
that's not easy. A lot of the complexities comes from this: for example, 
real to real fft is only implemented in fftpack right now; complex to 
complex and multi dimensional are available in fftw3 and mkl, complex to 
real available in fftw3. This makes refactoring fftpack as an API + 
different backends implementing this API wihout breaking anything tedious.

The other approach could be to drop all backends but fftpack, and 
forcing a new backend to implement the whole api (I would be willing to 
implement a full backend for fftw3 because it is open source, as well as 
djbfft, but no other).

cheers,

David