Re: FFT proposal for gsoc 2021

From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2021-04-02 08:02:26

  >>Â 2) Is the API implementable, i.e. can it be seamlessly and efficiently>> bound to existing implementations ? (To test this carefully this>> requires more than one backend, to avoid the API adopting idiosyncrasies>> from the first backend it was developed around.)
> Your point of view is very mature.> I am enthusiast to adhere to this idea.
This seems very practical and effective to me.
Thanks to everyone so far for the sensibleand wise inputs.
Kind regards, Chris

    On Thursday, April 1, 2021, 7:13:40 AM GMT+2, Eduardo Quintana via Boost <boost_at_[hidden]> wrote:  
 
 Hi Stefan,

On Wed, Mar 31, 2021 at 03:54:57PM -0400, Stefan Seefeld via Boost wrote:
> I agree, that wouldn't sound very appealing. I think the best way to
> look at it is to design a modern C++ FFT API, with a big "I", i.e. an
> emphasis on "interface", and to test that API by binding it to one (or
> two, if time permits) existing libraries.
>
> Testing such an interface has two sides:
>
> 1) Is the API accepted by users, i.e. is it convenient to use ?
>
> 2) Is the API implementable, i.e. can it be seamlessly and efficiently
> bound to existing implementations ? (To test this carefully this
> requires more than one backend, to avoid the API adopting idiosyncrasies
> from the first backend it was developed around.)

Your point of view is very mature.
I am enthusiast to adhere to this idea.

Eduardo

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost