[Numpy-discussion] BSD C port of FFTPACK incl. bluestein algorithm

[Charles R Harris]

On Fri, Nov 18, 2011 at 9:22 AM, Dag Sverre Seljebotn <
d.s.seljebotn at astro.uio.no> wrote:

> On 11/18/2011 01:18 PM, Dag Sverre Seljebotn wrote:
> > On 11/18/2011 12:58 PM, David Cournapeau wrote:
> >> On Fri, Nov 18, 2011 at 11:42 AM, Robert Kern<robert.kern at gmail.com>
> wrote:
> >>> On Fri, Nov 18, 2011 at 11:19, Dag Sverre Seljebotn
> >>> <d.s.seljebotn at astro.uio.no>   wrote:
> >>>> I've been in touch with Martin Reinecke, author of the libpsht code
> for
> >>>> spherical harmonic transforms, about licensing issues.
> >>>>
> >>>> libpsht itself will remain under the GPL, but he is likely to release
> >>>> his C port of FFTPACK under BSD in the near future, as it is based on
> >>>> the public domain FFTPACK.
> >>>>
> >>>> I'm grateful for this change for my own purposes (allows releasing my
> >>>> own competing SHT library under the BSD) -- but it could perhaps be
> >>>> useful for NumPy or SciPy as well, depending on how complete the port
> >>>> is? E.g., perhaps make numpy.fft more complete (is the
> >>>> numpy.fft/scipy.fftpack split simply because of the Fortran
> dependency?).
> >>>
> >>> It used to be the case that scipy.fftpack allowed one to build against
> >>> multiple different, usually faster, FFT libraries like FFTW. I think
> >>> we have backed away from that since the cost of maintaining the build
> >>> configuration for all of those different backends was so high. It's
> >>> worth noting that numpy.fft is already using a C translation of
> >>> FFTPACK. I'm not sure what the differences are between this
> >>> translation and Martin's.
> >
> > Here's some more info forwarded from Martin:
> >
> > """
> > - only FFTs are supported (no DCTs/DSTs)
> > - only double precision is supported (extension to single precision might
> >     not be much work, though)
> > - both complex and real FFTs are supported
> > - real FFTs allow various storage schemes for the (half)complex frequency
> >     domain data (classic FFTPACK scheme, FFTW or halfcomplex scheme,
> >     uncompressed complex storage)
> > - precision of transforms involving large prime factors should be
> slightly
> >     better than with original FFTPACK
> > - Bluestein's algorithm is automatically selected if considered
> profitable
> > - small accuracy self-testing code is provided.
> >
> > Fairly complete interface documentation is available in Doxygen format.
> > I'll prepare a source package later in the afternoon and send it around.
>
> OK, Martin sent me a BSD-ed version of his libfftpack, and I stuck it on
> github:
>
> https://github.com/dagss/libfftpack
>
> Note that ls_fft.h contains Martin's API for it (plan construction and
> execution etc.)
>
>
#define CC(a,b,c) cc[(a)+ido*((b)+cdim*(c))]

Hmm... ;) All in all, the code looks pretty readable, although the coding
style needs fixups and some of the macros using complex types are never
used and should be removed. The size_t type also needs to be replaced by
npy_intp for numpy. I think it is worth taking a closer look at integrating
the code.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111118/881ae2c3/attachment.html>