[SciPy-dev] Include patch in ticket {1} (slow fft when using fftw3) ?

John Travers jtravs at gmail.com
Fri Sep 22 12:41:21 CDT 2006

On 21/09/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:

> I'm going to continue looking at splitting support for the different fft
> packages out into separate files (especially now that support for the Intel
> MKL library has been added).

After recently hacking at the fftpack code the idea of reorganising
the fftpack files seems like a good one. I'm offering my services to
help! (esp. for MKL/fftw3).

I think you have posted before about this, but to get a better idea of
what your plan is, are you thinking of:

1. Exposing access to the underlying libraries in an advanced
interface? So that people who really care can control things more
easily (such as detailed fftw3 plans etc, saving fftw wisdom etc.)

2. Enabling the user to select which backend is used at runtime
(should be simple to implement if the above is covered), while
providing a reasonable default.

Some points about the above:

a. I think the first item would take some thought to get right due to
the size of the interfaces to these libraries. Simplifying it into a
reasonable python implementation could be done incrementally though I

b. We should make sure that performance isn't compromised in any way
and the generic (current) interface always works with at least current

c. We shouldn't try to add functionality just for the sake of it. For
me, access to the guru interface of fftw is very useful in my work as
I need very large numbers of ffts on the same data, but this could be
my minority case and the resulting interface may end up being too

d. It would certainly be easier to maintain the code if the basic
library functionality was separated (and all compiled if available -
getting rid of all those #idefs) - and then the high level generic
interface were in python only and selected the relevant library.

David, how far have you got with your efforts, and can I help in any way?
Anybody else have any comments or suggestions?

John Travers

More information about the Scipy-dev mailing list