Re: FFT proposal for gsoc 2021

From: Kostas Savvidis (kotika98_at_[hidden])
Date: 2021-04-02 12:12:33

> On Apr 2, 2021, at 11:18, Eduardo Quintana via Boost <boost_at_[hidden]> wrote:
> 
> Hello,
> 
> Thanks to all the feedback that I have had in the previous days I've finished version
> 2.0 of the Gsoc proposal. That you can find here:
> https://github.com/Lagrang3/gsoc-2021/releases/download/v2.0/gsoc.pdf
> 

Hi Eduardo,

It is clear that you have put a good effort into the proposal and that your understanding of underlying concepts 
is excellent. I would like to offer a comment on a few aspects of the proposal. 
Not to criticise you, but in the hope that it will increase the chances of funding the proposal and bring benefits to our beloved Boost.

1) The discussion of NTT. While boost.multiprecision can potentially be used to implement the Zp ring,
it currently does not contain any such construct.
Reading further, there is nothing about NTT in the deliverables.
If the idea is peripheral to the GSOC project, then it does not need to be mentioned at all.
Note that even the  PARI library does not yet have NTT implemented and for them I think it is a high priority (must be a very hard problem).

2) Section 2.2. Most people know the Convolution Theorem, but at least myself do not know anything about the Rader algorithm.
Since you propose to implement it, why not describe it in that Section, maybe instead of the  Convolution Theorem.

3) Section 2.3. You say: "FFTW was designed to compute DFT for complex numbers, like in Example 1.
There is no support for DFT in the broader sense of Definition 1. For example, we cannot use FFTW to compute the NTTs described in the Example 2." 
Since you are not going to be able to solve this problem in this GSOC project, it is better to not make such comments.

4) Section 2.3. "scalability of the parallel MPI routines for computing 3-dimensional DFT" , "domain decomposition" - here again I think it is
worth to remember that if the project is not going to address domain decomposition, then it is better to not talk about it.

5) Since this project is done under Boost, it seems logical to make sure  the proposed code
work with Boost.Math complex types. Is this not part of the plan? Why no word about it in the deliverables?

Best Regards,
Kostas