On 2021-03-11 1:55 p.m., Christopher Kormanyos via Boost wrote:
Hi Boost community, I've been working on a C++ templated library> for Fast Fourier Transforms ... Is there anyone interested in supervising this> project? Any opinions? Thank you for your interest and query.
Yes. I think I am interested and potentially qualifiedas 5 time GSoC mentor in Multiprecision and Math. The plan seems good, start with header onlysimple implementation and increase complexityand efficiency as time allows. This project would fill a present gap and wish listentry in Math/Multirpecision for those unable/unwillingto include FFTW. I will write a little project description at rthe relevantpage, link will follow...
At the risk of starting a long and fundamental discussion about Boost's fundamental goals, I'd like to suggest that we step back a little to consider different options. Reimplementing FFTs from scratch might be didactically useful for the person(s) doing that, but for the developer community not be of much interest if the quality of the result doesn't match already available options. And to think that you can match freely available FFT implementations (which have often evolved over decades) seems foolish. In that sense, the goal should *not* be to come up with a new and competitive implementation of an FFT library. Rather, I would like to propose a slightly different approach: 1) Develop a C++ API that can be used as a thin layer over one or two existing FFT "backend" libraries (FFTW seems a natural choice). 2) Implement that same API "from scratch", but without much effort put into performance. The goal isn't to out-perform existing implementations (which would take many years of effort !), but to provide a functionally complete and correct reference implementation, useful for testing. This would open the door for future additions of other back-ends, useful for developers who are unable or unwilling to use the primary back-end itself. (Note that the selection of the backend could be done at compile-time or at runtime, depending on the available hardware, including GPUs or other accelerators. Designing a clever dispatch mechanism to pick the "best" backend given a particular problem set (problem size, data types, data layout, etc.) is itself a complex problem worth considering...) --- In a nutshell, the goal should be a modern C++ API that is convenient to use and which can be bound to different backends for top performance, yet avoiding explicit dependence on specific implementations. Stefan -- ...ich hab' noch einen Koffer in Berlin...