Re: [boost] FFT proposal for gsoc 2021

On Mar 31, 2021, at 15:46, Stefan Seefeld via Boost wrote: On 2021-03-31 3:12 a.m., Eduardo Quintana via Boost wrote:

...

...

By looking at the surface of the code, I see that they've built their own complex type based on double and it even has arithmetic operations. That's a great improvement with respect to FFTW's POD fftw_complex. Yet I don't see why they couldn't use std::complex<double>?

Arguably, adding custom complex types in FFTW++ just makes matters worse, as users of that API now have two distinct C++ complex types to deal with.

You guys are quite unfair to your competitor ;) On line 77 of fftw++.h I find: typedef std::complex<double> Complex; On the other hand, everything is done in their own sophisticated multi-matrix class. The other thing is that fftw++ is not just a simple wrapper and implements their zero-copy zero-storage "dealias" technique from the paper. "Efficient Dealiased Convolutions without Padding," by John C. Bowman and Malcolm Roberts, SIAM Journal on Scientific Computing, 33:1, 386-406 (2011).