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