Re: FFT proposal for gsoc 2021

From: Stefan Seefeld (stefan_at_[hidden])
Date: 2021-03-30 17:44:28

Hi Eduardo,

On 2021-03-30 1:01 p.m., Eduardo Quintana via Boost wrote:
> Wrapping FFTW is not a priority I have. I believe that the right way 
> to work
> towards an FFTW/C++ api will be to do so directly into the FFTW project. Sooner
> or later someone will do it.
>
> What I want to bring to Boost.Math are "Generic Programming" FFT algorithms
> for situations that FFTW can't handle. And I want them to have decent
> performance for complex numbers, I do not aim to outperform FFTW.

What you have in mind may be an acceptable goal for a stand-alone FFT 
library, especially if this is a learning exercise, but as a 
contribution to Boost I think it falls short.

Boost's stated goal is to defined modern C++ APIs for common sets of 
functionality, perhaps even finding their way into future C++ standards. 
As such, it's important to consider the (end-)user expectations, which, 
especially for a math-centered library, includes the "three Ps":

* Portability
* Performance
* Productivity

As a user I don't want to see another FFT library that may work well in 
some cases but not others. I simply want to be able to use it and trust 
that its performance is good no matter the platform, and no matter the 
problem type (real vs complex, dimensionality, data layout, size, etc.).

If I have to add logic to switch between APIs depending on those 
parameters, I'm no longer productive. If I only get good performance in 
some cases (compared to existing and popular libraries), I'm no longer 
efficient. Etc.

Please keep this in mind when proposing a project whose ultimate goal is 
to be accepted into Boost.

Thanks,

Stefan
-- 
       ...ich hab' noch einen Koffer in Berlin...