![](https://secure.gravatar.com/avatar/9820b5956634e5bbad7f4ed91a232822.jpg?s=120&d=mm&r=g)
Robert Kern wrote:
I'd drop FFTW and MKL support first before djbfft because they are not compatible with the scipy license.
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),
Ok. 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