Re: FFT proposal for gsoc 2021

From: Eduardo Quintana (eduardo.quintana_at_[hidden])
Date: 2021-03-31 18:58:20

 ('
' encoding is not supported, stored as-is)
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