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