[SciPy-dev] Dropping djbfft ?

[Anne Archibald]

2008/5/12 David Cournapeau <david at ar.media.kyoto-u.ac.jp>:
> Robert Kern wrote:
>>  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).

How about a third approach (which I think may be what Robert Kern was
suggesting)? Simply SWIGify (or cythonify or f2pyify) each library, so
that they each provide their own API to python. Then write the
detection/wrapper code in python, where it's relatively easy to muck
about with dispatching and API finagling.

Would there be a big performance hit for operations that do many small
FFTs? Is there much code that calls the FFTs at a C level?

Anne