Stefan Seefeld via Boost said: (by the date of Wed, 31 Mar 2021 15:54:57 -0400)
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. :-)
Yes! Make the interface general. Test with various examples (e.g. matrices) and/or libraries. With the future goal to allow performing Fourier transforms of everything that provides Nth root of unity. Maybe even a template check + a compiler error when such root is not found. This can help in creating a sound design of the interface. best regards Janek -- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdańsk University of Technology Faculty of Applied Physics and Mathematics Department of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/jkozicki (click English flag on top right)