Boost logo

Boost :

From: Stefan Seefeld (stefan_at_[hidden])
Date: 2021-03-14 17:19:03

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

(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.
       ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at, gregod at, cpdaniel at, john at