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. That's as close as I can image to duplicate effortlessly someonelse's work. Also I wouldn't be honest with you if I say so. The project I originally proposed is a different thing. However, I don't want to be stuborn. I publicly posted the idea here because I wanted to listen to experts opinion. I am glad I did. Hence I will soon upload a proposal 2.0 where I will give more space to the FFTW wrapper thing.
Stefan Seefeld via Boost said: (by the date of Wed, 31 Mar 2021 08:46:17 -0400)
Consider using template meta-programming to identify whether the data types and layout are supported by FFTW, and if so, call that, else call a different backend. Then as an end-user I don't have to think about such choices, and can simply trust that I get the best performance available.
I like Stefan's idea. For the new proposal there will be something of the like.
However the first priority in GSOC in my opinion should be:
1. wrapping fftw and 2. designing a general interface that allows wrapping all the other types
But I don't want to spend too much time wrapping FFTW. I'm thinking of providing a very basic back-end, at least to cover one dimensional single and double precision, complex to complex and real to complex cases and everything else is optional. Handling plans, stride memory, D-dimensional, MPI and multi-threaded cases I will leave for post-GSOC. Thank you for the feedback. Eduardo