Re: [boost] Request to contribute boost::FFT

Subject: Re: [boost] Request to contribute boost::FFT
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2013-06-03 09:48:24

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