[SciPy-dev] Cleaning and fixing fft in scipy ?

[David Cournapeau]

John Travers wrote:
> On 02/05/07, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
>>     - My understanding is that except for djbfft backend, all other
>> backend implement fft of any size (eg different than 2^n); so for djbfft
>> backend, for size different than 2^n, it uses a diffferent backend. For
>> example, if FFTW (v2) is selected and djbfft detected, then the zfft
>> function is effectively using 2 backend: djbfft and fftw2. Would it be a
>> big problem if in djbfft case, the sizes != 2^n are always handled
>> through a fixed backend (fftpack I guess) ?
>
> Well, probably not, as people using djbfft probably know what they are
> doing. But It does seem a bit drastic to drop from the fastest backend
> to the slowest if say fftw or MKL is also installed. Especially as
> this would provide lower performance than the current implementation.
If fftw or mkl is installed, I am not sure djbfft would be used anyway. 
It may have been the fastest fft a few years ago, but I cannot repeat 
any of the results given on djbfft with recent CPU (and by recent, I 
mean a pentium 4, that is already a few years old) and compilers. More 
fundamentally, if you care about efficiency fpr fft, you use 2^N size.
>
> But why is this necessary anyway? It is only decided at compile time
> right? 
The goal of the reorganization was:
    - to make easier to read existing code
    - to make it easier to add additional backends

It was a bit complicated to support point 2 with only C macro in a 
reliable way (because of djbfft exception, like the ones I assume you 
put for mkl/djbfft). But after having thought a bit, I took a totally 
different approach: I am now generating the code with a python script 
(see my other email), such as adding a backend just consists in writing 
your implementation in a C file, and regenerating the python script.

David