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

[David Cournapeau]

Pearu Peterson wrote:
> On Sat, April 28, 2007 1:06 pm, Pearu Peterson wrote:
>
>> 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.
>
> I now reread your original proposal and I think that this condition
> can be relaxed provided that after applying any patches to
> scipy.fftpack all fftpack unittests pass ok.
Thanks for your email, Pearu. I would certainly not submit a patch which 
do not pass the unittest; problem being I cannot test all 
implementations (I can test fftpack/fftw2/fftw3 on Linux easily; I 
cannot get djbfft to compile on my machine; if necessary, I can install 
the MKL; I don't know whether OS and compiler matters a lot for fftpack, 
as I don't intend to touch the setup part).

I think that I was not really clear in my former emails: I do not 
suggest a rewrite, but a 2 steps improvements:
    - one which does not change anything to the code except its 
organization (one file for one fft API instead of the #ifdef)
    - once the first step is done and considered acceptable by the scipy 
developers, I would like to improve fftw3, such as it is at least on par 
with fftw2: right now, for fftw3, the arrays are copied twice. I think 
fftw3 requires a more sophisticated caching scheme, because with fftw3 
you cannot use the same plan when the input/output are changed, at least 
with the basic API. For example, Octave is using such a scheme. Other 
implementations would be untouched.

    Cheers,

    David
>
> Pearu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>