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.
_______________________________________________
Help-gsl mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gsl
