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