[SciPy-User] [ANN] pyfftw-0.2 released

[David Cournapeau]

On Tue, Feb 16, 2010 at 7:23 AM, Jochen Schroeder <cycomanic at gmail.com> wrote:

> I still think this is a very good idea. What were the main objections around
> this at the time?

No real objection per se, but IIRC, it was made complicated for
platforms without an aligned memory allocator. For example, for
platforms with posix_memalign, you can free the returned memory block
with the standard free. If you implement your own aligned memory
allocator (which is easy), you need to match with your own free.

The only sane way to do that in NumPy is to *always* allocate with an
aligned allocator. Doing so is not easy because of realloc (an aligned
realloc is impossible to implement without going into the libc malloc
internals). So the idea was to ban realloc inside numpy altogether
(there are only a few realloc calls in numpy), but I never took the
time to look more into it.

>
> Well I looked at creating a more "traditional" API around fftw (something like
> y=fft(x)) but the performance benefit for relatively small arrays (in my
> experience ~2**12) was mainly eaten up by the creation of the output array.

It depends on the application, of course, but in audio processing, you
generally takes M fft of M signals of size N (so you do ff(x) with x a
2d array, and the fft is done on each row or column). So this is not a
big issue (as long as you can fit the whole signal in memory, that
is).

I think providing a "high" level API ala scipy.fftpack should be
doable - actually, having a scikits which can be used as a drop-in for
scipy.fftpack but using fftw would be very useful,

cheers,

David