On Tue, Sep 24, 2013 at 12:28 PM, Nathaniel Smith <njs@pobox.com> wrote:
>
> On Mon, Sep 23, 2013 at 8:51 AM, Dag Sverre Seljebotn
> <d.s.seljebotn@astro.uio.no> wrote:
> > On 09/21/2013 08:57 PM, Ralf Gommers wrote:
> >> fftpack
> >> ```````
> >> Needed:
> >>
> >> - solve issues with single precision: large errors, disabled for
> >> difficult sizes
> >> - fix caching bug
> >> - Bluestein algorithm nice to have, padding is alternative
> >
> > A battle-tested Bluestein is included in Martin Reinecke's C port of
> > FFTPACK.
> >
> > https://github.com/dagss/libfftpack
> >
> > As you can see in the readme there were a couple of changes to FFTPACK
> > to improve accuracy for large primes.
>
> If this is nicely-licensed C code that provides a superset of
> scipy.fftpack's functionality, ought we to merge it into *numpy*.fft
> and deprecate scipy.fftpack?

It does not provide a superset. The FORTRAN code in scipy.fftpack does ND transforms, the DCT and DST, and FFT-based convolutions. None of that code *must* remain in FORTRAN, but you would have to rewrite it all in C using the new libfftpack C code underneath. It's not a matter of "merging", I'm afraid, but significant rewriting.

> (I'm a little confused at what exactly
> the difference between the numpy and scipy modules is in this case,
> except that of course the scipy version needs a fortran compiler.)

At one time, scipy.fftpack supported several different backends like FFTW, not just the FORTRAN FFTPACK. They have since been dropped because they added more difficulties to the build process than we gained in performance.

--
Robert Kern