Re: FFT proposal for gsoc 2021

From: Kostas Savvidis (kotika98_at_[hidden])
Date: 2021-03-31 13:35:17

> On Mar 31, 2021, at 15:46, Stefan Seefeld via Boost <boost_at_[hidden]> 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).