Hi Eduardo, On 2021-03-30 6:58 a.m., Eduardo Quintana via Boost wrote:
I've written and uploaded a first draft proposal to GSOC-2021 for the Boost.Math.FFT library. https://github.com/Lagrang3/gsoc-2021/releases/download/v1.0/gsoc.pdf I realize now that maybe I should have given more details about the proposal itself, like user's interface and implementation ideas. That can be fixed in version 2.0.
Your schedule above looks very ambitious, and, I fear, quite unrealistic: You plan a single week (June 7 - June 13) for * defining the API for your FFT library * implementing it * writing tests for it * writing benchmarks for it * documenting (part of) it Unless the bulk of this is already done, and the tasks merely consist of polishing the code and integrating it into a new special-purpose git repo, I don't think this will work. For that reason, as well as for reasons I already outlined in a previous post, I strongly suggest you change the ordering (and timing) of your milestones, to first focus on an API that can be implemented as a wrapper around FFTW (as I suspect that will be the implementation most developers will use until you have an alternative that actually out-performs FFTW), and only then start to re-implement your API with other backends (including your own). That will allow you to realize that you won't be able to meet all your goals, and still make this project a success, i.e. have something actually usable. If you end up with a library that works, but doesn't perform well, I'm afraid it won't attract any users, which would be a pity, wouldn't it !? Stefan -- ...ich hab' noch einen Koffer in Berlin...