Re: [Help-gsl] 2d FFTs, DCTs, etc.

[Dimitris Papavasiliou]

James Bergstra wrote:
> Admittedly, what I had in mind was in fact a third interface, that adds
> considerable code, and no new functionality.  I don't believe that it should
> replace the gsl fft api.  I like the extension system, and I think this is the
> sort of thing that would make a good extension.
>
> My goal was an API that is as easy to call as gsl's, and that admits an FFTW
> implementation, but doesn't require it ( gsl has a priority of being
> self-contained).
>   
Yes, that function prototype you mention later on easily convinces one
of the usefulness of what you're proposing...
> > *  Your interface is simpler, but then it's entirely incompatible with 
> > the current GSL FFT routines and I don't know whether Brian Gough and 
> >     
> Right, this is a pretty fat whole in my plan.  If someone asks for a gsl
> implementation of a 2d-fft, my api will have to throw an error.  As it stands, 
> FFTW is the way to go for multi-d parallel transforms.  The question is how easy
> can we make the transition, for people who have invested in the gsl data types.
>   
Why provide the GSL routines as well?  Since you're redesigning the
whole thing why not just use the GSL data types and combine them with
just FFTW?  You'll have the same functionality and FFTW probably
outperforms the GSL anyway, doesn't it?

Aside from that I was initially thinking of implementing
multidimensional FFTs, but you'll run into two problems:
a) The GSL doesn't have data structures for n-D data where n > 2 (until
the tensor library , and
b) Some transforms, basically the real in-place transform should be
hard, if possible, to implement for multidimensional data (it might be
possible for two dimensions although I'm not sure).

So I've come to the conclusion that, since n-D FFTs are just a matter of
n for loops (I was going to use row-column methods) they might as well
be left to the user, instead of breaking interface symmetry.  At least
in that case he'll know exactly what is going on under the hood, and
I'll have less work to do as well :).
> I don't think it's as bad as you think.  You can use FFTW to implement the gsl
> API for example.  The loading of wisdom files is optional, and the search can be
> limited by choosing the FFTW_ESTIMATE flag.  By estimating, and using no wisdom,
> FFTW uses a default algo that can depend on your alignment and the input size.
> Even in this default case it's still fast.  I just wanted to set up the api so
> that it's easy to optionally "optimize" later by changing a flag from
> FFTW_ESTIMATE to FFTW_MEASURE and adding a load-wisdom statement somewhere.
>   
> > one post about FFTW.  This leads me to theorize that someone in need of 
> > a smoking fast FFT routine probably doesn't need a generic math library 
> > and is happy with a specialized package.  On the other hand if most GSL 
> >     
> I dispute this, even someone who is happy with a specialized package may balk
> at debugging code that calls a function like this:
>
> fftw_plan fftw_plan_many_dft_r2c(
>     int rank,
>     const int *n,
>     int howmany,
>     double *in,
>     const int *inembed,
>     int istride,
>     int idist,
>     fftw_complex *out,
>     const int *onembed,
>     int ostride,
>     int odist,
>     unsigned flags);
>
> It smooths/speeds things appreciably to start with a working example or
> demonstration of how to do it.  An API would provide the mapping of how to
> convert gsl_matrix and gsl_matrix_complex arguments into this stuff.
>   
Well you're probably right on both these points.  I just haven't
actually used the FFTW and it seemed pretty complex to me (well that
guru interface doesn't sound too simple).  If you don't try to expose
the whole API it should be ok.  It just that when you get involved with
a complex piece of software things usually tend to get messy, no matter
how simple it seemed at the beginning.


Dimitris P.