On Monday, June 03, 2013 02:44:03 PM Mathias Gaunard wrote:
On 03/06/13 14:15, Arash Partow wrote:
On 3/06/2013 7:39 AM, Mathias Gaunard wrote:
It's a pure computation function; the interface should just be a couple of functions taking pointers.
That would be a very naive and pedestrian approach.
Factors ranging from the input type (real, complex, integer), dimensionality of the data, the way the data is stored, the precision required, application of the transform (lets think about multiplications for Strassen), phase rotation et al.
Different function names for different variants. You may also use overloading.
So what we should be heading for is not another CRC library (which should really be part of a generalized message digest library), but rather a well thought-out and designed interface that is extensible with provisions for future support of multiple backends (fftw, ipp, cuda, opencl et al) and types (float, double, mp, et al) - and not just the first meta idea that easily scales in our minds. ;)
In short - A couple functions with a few pointers would fall dismally short of the 'mark'.
Yet it is what is needed to fulfill your requirements.
afaik fft methods need temporary working space. this might already be a strong enough argument to encapsulate methods into classes. I dont think "just a few functions" is enough here. I would really like to see a generic fft libraries, that can also run on multi-precision types. Mario
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost