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