[SciPy-dev] fft benchmarks for new routines

[Pearu Peterson]

Chuck,

On Mon, 12 May 2003, Chuck Harris wrote:

> >Then we should bench your algorithms also against FFTW as FFTW is faster
> >than FFTPACK.
> 
> Where are the wrappers for FFTW? They seem to have disappeared from
> scipy, certainly they didn't come down with the latest CVS update.

FFTW as well as other FFT backends are wrapped by scipy.fftpack.

For example, see fftpack/src/zfft.c that defines 

  void zfft(...)

This C function calls either FFTW, FFTPACK or DJBFFT routines depending
on whether cpp-macros WITH_DJBFFT or WITH_FFTW are defined.
These macros are determined from calling

  scipy_distutils.system_info.get_info('djbfft')
  scipy_distutils.system_info.get_info('fftw')

in fftpack/setup_fftpack.py. In general, setup_fftpack.py should pick up
FFTW libraries when available, Otherwise FFTPACK is used. See
fftpack/NOTES.txt for more information how to build scipy.fftpack with
a particular FFT backend.

The C function zfft itself is wrapped using f2py. See

  fftpack/_fftpack.pyf

that defines _fftpack extension module.

And finally, _fftpack.zfft is called from fft Python function defined
in fftpack/basic.py.



> What order is preferred for the real transforms? The most natural order
> for my routine is real in the bottom and imaginary reversed in the top.

So this is the same as in FFTW:

  http://www.fftw.org/fftw3_doc/The-Halfcomplex-format-DFT.html

> Not reversing the top is easy, but interlacing real and imaginary is more
> difficult and time consuming.

scipy currently uses FFTPACK convention, that is, rfft(x) returns

  [y(0),Re(y(1)),Im(y(1)),...,Re(y(n/2))]

where y is FT of real x. See scipy.fftpack.rfft.__doc__ for a complete
definition.
Btw, Numeric.real_fft uses the same convention (because it uses f2c
version of FFTPACK) but returns y as a complex array. 

Pearu