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
> > 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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk