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

[Dimitris Papavasiliou]

James Bergstra wrote:
> I'd say the template thing is not worth the pain for two types.  But as for
> helping out, I'd be happy to.  For starters, if you like, I can set you up with
> a project in libmsl (hosted on savannah).  It, already has cvs space, autotools
> are already configured, etc.  Let me know if you like my design idea, and if
> you'd like admin status in libmsl.  I'm supposed to be doing a masters thesis
> too, but it doesn't stop me from coding away... :P
Hi James,

your design idea (something like it) was the first thing that popped 
into my head actually when I was looking for a DCT routine.  I was 
wondering why the GSL didn't use FFTW (which seems to be the most 
popular fft implementation).  But after taking a look at FFTW I realized 
that it was more complex in just computing FFTs than the GSL in doing 
everything it does (at least what I've used so far).  You've got 
multiple interfaces, multiple functions for similiar things within 
those,  wisdom files you can save and load etc.

So my points are:
*  Wrapping all of the functionality of FFTW in GSL (all interfaces, 
wisdom saving, etc.) would be, I feel, too complex for a general library 
like the GSL, but then again that's not my call, and it's not what 
you're proposing either (is it?).
*  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 
the other GSL developers would be willing to change the API.  You would 
probably still have to make a few choices though (so you'll have to keep 
implementation details in mind when all you want is a DFT) and I'm not 
sure whether we would be able to get away with not using saved wisdom 
files as calculating plans takes some time (from what I've read).  I 
fear things will have to get complicated.
* My main problem is that I don't think that I'm qualified for this.  I 
can probably handle the coding but I don't have much practical 
experience with FFTs (I'm in the graphics business) to know what's 
necessary and what's not.  For example searching the archives I see only 
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 
users just need reasonably fast DFTs then it would be a bad idea to 
force the complexity of plans, etc. on them.  But as I've said I don't 
have enough practical experience to know whether I'm right or not.  I 
also don't need FFTs (well only real radix2 FFTs) so it won't be easy 
for me to test all that stuff thoroughly.

So I was thinking of patching up GSL's FFT routines (by adding 
gsl_vector functions) if the developers of GSL don't have a good reason 
for the asymmetry in the FFT interface (the wavelet interface also lacks 
float functions) and add a DCT.  As for libmsl, if what I have in mind 
still interests you I'd be happy to host it there.  I haven't released 
code until now so I'm not familiar with the use of autotools and the 
general procedure of polishing something for release.  By the way, home 
come libmsl isn't mentioned in the GSL site?  Is it supposed to be a 
separate library of extensions or extensions to be incorporated into GSL 
at some point?

Dimitris P.