[SciPy-Dev] Scipy 1.0 roadmap

[Dag Sverre Seljebotn]

On 09/24/2013 03:53 PM, Robert Kern wrote:
> On Tue, Sep 24, 2013 at 12:28 PM, Nathaniel Smith <njs at pobox.com
> <mailto:njs at pobox.com>> wrote:
>  >
>  > On Mon, Sep 23, 2013 at 8:51 AM, Dag Sverre Seljebotn
>  > <d.s.seljebotn at astro.uio.no <mailto:d.s.seljebotn at 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.

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?

Dag Sverre