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

[Pearu Peterson]

On Sat, April 28, 2007 10:16 am, David Cournapeau wrote:
> Travis Oliphant wrote:
<snip>
>> I don't mean to discourage effort here.  I'm just hesitant to start
>> changing things without some kind of feedback from the original author
>> (Pearu in this case).
> I agree, and that's exactly why I send this email.

I certainly agree that scipy.fftpack implementation can be improved
(as any piece of software). The current implementation was an attempt
to support a large number of different fft implementations (they all
have their own pros-and-cons) that had (sometimes very) different
APIs.  And hence the complexity of the current implementation. If I
would start rewriting scipy.fftpack then I would probably choose a
different approach to the current one too. However, I doubt that any
other implementation with the same goal would be easy to understand or
read to non-authors due to a variety of APIs of different fft
implementations.

In summary, I am not against to rewriting scipy.fftpack provided that
1) it is carried out in scipy.sandbox until it becomes more-or-less
equivalent to the current scipy.fftpack in terms of features, unit-testing,
supported fft backends, and documentation.
2) there are performance tests demonstrating that the new implementation
outperforms the old one at least with the following backends: Fortran
fftpack (that is default for most users), fftw2, and fftw3.

Finally, I would also like to note that the efficiency of scipy.fftpack
cacheing should be tested against both short sequences (N=64,..,512)
as well as for long sequences (N>1024) as the same scheme could be very
dependent of the sequence size when regarding perfomance.

Best regards,
Pearu