[SciPy-Dev] Scipy 1.0 roadmap
Dag Sverre Seljebotn
Tue Sep 24 15:07:53 CDT 2013
On 09/24/2013 03:53 PM, Robert Kern wrote:
> On Tue, Sep 24, 2013 at 12:28 PM, Nathaniel Smith <firstname.lastname@example.org
> <mailto:email@example.com>> wrote:
> > On Mon, Sep 23, 2013 at 8:51 AM, Dag Sverre Seljebotn
> > <firstname.lastname@example.org <mailto:email@example.com>> 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.
It seems to me all the FORTRAN code there is plain vanilla Netlib
FFTPACK; the extra ND and convolutions etc. are in C?
But indeed, seems like Martin's C port doesn't include the DCT and DST
parts of FFTPACK, only complex and real FFT. That makes it not
completely trivial, but I wouldn't say "significant rewrite" is accurate
either, it's just about making the C port of FFTPACK complete.
Martin (on CC), how long did it take to port the complex/real FFTs from
Fortran to C?
More information about the SciPy-Dev