Boost logo

Boost :

From: Janek Kozicki (janek.listy.mailowe_at_[hidden])
Date: 2021-03-31 15:12:11


Eduardo Quintana via Boost said: (by the date of Tue, 30 Mar 2021 17:01:43 +0000)

> Wrapping FFTW is not a priority I have. I believe that the right way to work
> towards an FFTW/C++ api will be to do so directly into the FFTW project. Sooner
> or later someone will do it.

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.

Of course major design goal is to design a fftw wrapper in such a way
that following is possible:

> What I want to bring to Boost.Math are "Generic Programming" FFT algorithms
> for situations that FFTW can't handle.

So that for the types handled by fftw the fftw library would be used.
And for other types, such as Matrices or Clifford algebra,
the more generic solution will be used. 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

Then, if time permits add FFT for one of the other "fancy" types.

Stefan Seefeld via Boost said: (by the date of Wed, 31 Mar 2021 08:46:17 -0400)

> Arguably, adding custom
> complex types in FFTW++ just makes matters worse, as users of that API
> now have two distinct C++ complex types to deal with.

Yes, completely agree. I think, that since this work is done on par
with boost::multiprecision, then only the C++ fundamental types and
boost::multiprecision types should be supported.

With later addition (see point 2. above) of types constructed from
them, such as matrices.

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

Yes, this is a very important point.

> Etc., etc., there are many things left on the table that don't involve
> re-writing FFT kernels from scratch !)

Agree.

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)

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk