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...