[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dimitris Papavasiliou
Subject: Re: [Help-gsl] 2d FFTs, DCTs, etc.
Date: Fri, 12 May 2006 18:59:28 +0300
User-agent: Mail/News 1.5 (X11/20060228)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]