What is the difference between numpy.fft and scipy.fftpack?

Question

Is the later just a synonym of the former, or are they two different implementations of FFT? Which one is better?

Solution 1

SciPy does more:

• http://docs.scipy.org/doc/numpy/reference/routines.fft.html
• http://docs.scipy.org/doc/scipy/reference/fftpack.html#

In addition, SciPy exports some of the NumPy features through its own interface, for example if you execute scipy.fftpack.helper.fftfreq and numpy.fft.helper.fftfreq you're actually running the same code.

However, SciPy has its own implementations of much functionality. The source has performance benchmarks that compare the original NumPy and new SciPy versions. My archaic laptop shows something like this:

                 Fast Fourier Transform
=================================================
      |    real input     |   complex input    
-------------------------------------------------
 size |  scipy  |  numpy  |  scipy  |  numpy 
-------------------------------------------------
  100 |    0.07 |    0.06 |    0.06 |    0.07  (secs for 7000 calls)
 1000 |    0.06 |    0.09 |    0.09 |    0.09  (secs for 2000 calls)
  256 |    0.11 |    0.11 |    0.12 |    0.11  (secs for 10000 calls)
  512 |    0.16 |    0.21 |    0.20 |    0.21  (secs for 10000 calls)
 1024 |    0.03 |    0.04 |    0.04 |    0.04  (secs for 1000 calls)
 2048 |    0.05 |    0.09 |    0.08 |    0.08  (secs for 1000 calls)
 4096 |    0.05 |    0.08 |    0.07 |    0.09  (secs for 500 calls)
 8192 |    0.10 |    0.20 |    0.19 |    0.21  (secs for 500 calls)

It does seem that SciPy runs significantly faster as the array increases in size, though these are just contrived examples and it would be worth experimenting with both for your particular project.

It's worth checking out the source code http://www.scipy.org/Download#head-312ad78cdf85a9ca6fa17a266752069d23f785d1 . Yes those .f files really are Fortran! :-D

Solution 2

I found that numpy's 2D fft was significantly faster than scipy's, but FFTW was faster than both (using the PyFFTW bindings). Performance tests are here: code.google.com/p/agpy/source/browse/trunk/tests/test_ffts.py

And the results (for n x n arrays):

           n                sp               np             fftw
           8:         0.010189         0.005077         0.028378
          16:         0.010795         0.008069         0.028716
          32:         0.014351         0.008566         0.031076
          64:         0.028796         0.019308         0.036931
         128:         0.093085         0.074986         0.088365
         256:         0.459137         0.317680         0.170934
         512:         2.652487         1.811646         0.571402
        1024:        10.722885         7.796856         3.509452

Solution 3

Looking at the github respositories for each, scipy is not just importing numpy's version and renaming it (although it does borrow some functionality). You'll have to dig into the code if you want to discern the difference in implementations since the documentation doesn't make a direct comparison.

https://github.com/numpy/numpy/tree/master/numpy/fft

https://github.com/scipy/scipy/tree/master/scipy/fftpack

Comments

[dtlussier]

Any idea why they chose to maintain two different implementations?

[keflavich]

As a sidenote, I think the speed will depend strongly on what supporting packages you've compiled for numpy/scipy, e.g. if you've compiled BLAS/LAPACK and with which compiler and compiler flags. But I don't know which compilers/flags are faster =(

[endolith]

scipy's fft checks if your data type is real, and uses the twice-efficient rfft if so. numpy's fft does not.

[Corvus]

scipy returns the data in a really unhelpful format - alternating real and imaginary parts after the first element. Once you've split this apart, cast to complex, done your calculation, and then cast it all back, you lose a lot (but not all) of that speed up. Basically it is not a fair comparison - numpy's time include making the output usable, not just doing the fft.

[nick maxwell]

Also, check out hgomersall.github.io/pyFFTW/pyfftw/interfaces/interfaces.htm‌​l It's a nice wrapper for fftw that works as a drop-in replacement for numpy.fft or scipy.fftpack.

[divenex]

Numpy uses a C porting of the FFTPACK Fortran programs, while Scipy uses the original Fortran version.

[ZisIsNotZis]

You can use dtype tricks to view the "alternating" array as array of complex numbers (except for the first element I believe) @Corone

[fqq]

@ZisIsNotZis can you expand on that?

[EntangledLoops]

"It does seem that SciPy runs significantly faster..." - based on what? What are the units in your benchmark? Where is the test code? Did you use the same compilation options for the backends? If SciPy is just calling Numpy for some of these routines, the difference is just random variation.