[SciPy-dev] Cleaning and fixing fft in scipy ?
David Cournapeau
david at ar.media.kyoto-u.ac.jp
Sat Apr 28 06:52:18 EDT 2007
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
>
>
More information about the SciPy-Dev
mailing list