[SciPy-dev] Renaming fftpack to fft, removing backends

Jarrod Millman millman@berkeley....
Tue Oct 28 06:31:22 CDT 2008


On Tue, Oct 28, 2008 at 1:49 AM, David Cournapeau
<david@ar.media.kyoto-u.ac.jp> wrote:
> renaming scipy.fftpack -> scipy.fft
> ===================================
>
> Rationale: fftpack is the name of an implementation (fftpack being the
> name of the Fortran library we use when no other fft library is
> available), and does not fit the convention of any other scipy top
> subpackage.
>
> How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
> placeholder (like scipy.linsolve), and deprecating scipy.fftpack.

+1

> Removing all backends but fftpack
> =================================
>
> Rationale: we have 5 backends (fftpack, djbfft, fftw2 and 3, mkl), and
> none of them is complete. I would much prefer focus on one (fftpack),
> make it complete (for example supporting float32 type), than having 5
> half implemented ones. Although, more backends mean more reliability
> problems for installation, distribution, support, etc...
>
> People may argue that fftw3 or MKL is faster: it is true in theory, but
> in practice, not so much. In particular, with the current
> implementation, both fftw2 and fftw3 are as fast or even slower than
> fftpack (because the wrappers are relatively naive, and do not use fftw
> effectively to get max speed). MKL is faster, but a lot of
> functionalities are missing for this backend.
>
> How: putting all the code not related to fftpack to a scikits or
> something, so people who really need the speed can use this. Since you
> need to compile scipy by yourself anyway for MKL, I don't see this as a
> huge problem.

+1

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


More information about the Scipy-dev mailing list