Re: FFT proposal for gsoc 2021

From: Stefan Seefeld (stefan_at_[hidden])
Date: 2021-03-31 19:54:57

Hi Eduardo,

On 2021-03-31 2:58 p.m., Eduardo Quintana via Boost wrote:
> Hi Janek,
>
>> I think this is a mistake. Best approach is to not duplicate existing
>> work, especially when it is written by the experts in the field.
> You are right. But I cannot say that the main goal is to design an FFTW wrapper.

I agree, that wouldn't sound very appealing. I think the best way to 
look at it is to design a modern C++ FFT API, with a big "I", i.e. an 
emphasis on "interface", and to test that API by binding it to one (or 
two, if time permits) existing libraries.

Testing such an interface has two sides:

1) Is the API accepted by users, i.e. is it convenient to use ?

2) Is the API implementable, i.e. can it be seamlessly and efficiently 
bound to existing implementations ? (To test this carefully this 
requires more than one backend, to avoid the API adopting idiosyncrasies 
from the first backend it was developed around.)

In a nutshell, the above involves a substantial amount of work. 
Describing it as "design an FFTW wrapper" wouldn't do it justice. :-)

And by the way, I would suggest the exact same approach for the 
`Boost.XML` proposal, for exactly the same reasons. (As it happens I 
tried this approach many years ago. Then my own interests shifted, and I 
could never finish the project. If anyone is interested, feel free to 
steal ideas from https://github.com/stefanseefeld/boost.xml.)

Best,

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