On Thu, May 11, 2006 at 07:09:16PM +0300, Dimitris Papavasiliou wrote: ... > Now what I'm interested in is the following: > a) Is there an interest in such a package (1D, 2D, DCTs, 2D FFTs maybe > and vector/matrix interfaces for the lot) or should I just implement > DCTs for myself? I'm asking because these things are easy enough to > implement that I thought there might be a reason why they aren't > provided by the GSL yet. > b) Is there a reason why there are no vector/matrix interfaces to the > fft functions (in constrast to the wavelets routines)? > c) Is there a reason why there are no two-dimensional fft routines? For > real data there would be the problem of computing them in-place I > suppose but for complex data computation is pretty simple using > row-column decomposition.
An excellent idea! However, I'd like to suggest that if you make an FFT interface, that you make the implementation swapable (at runtime?) between gsl's fft stuff and FFTW. FFTW is like ATLAS for FFTs. It also performs the DCT. It also handles multi-dimensional transforms, and it can compute several of them in parallel if that's what you want. It's an excellent library for computing ffts. The catch is that fftw3 uses the notion of a "plan" which encapsulates data about the size/location/alignment of your input and output buffers. Therefore, it is possible to support a routine like my_fft(gsl_matrix * in, gsl_matrix_complex * out) but it is awkward. This all leads up to my constructive follow-up... which is how I'd like to see FFT's handled :) I'd suggest writing up an FFTW-like API with additional plan-construction routines that accept gsl data types. For example, typedef void * my_plan_t; void my_plan_free(my_plan_t); void my_plan_exec(my_plan_t); my_plan_t my_plan_raw( double *, stride, complex_double *stride, flags, etc...) my_plan_t my_plan_gsl( gsl_vector * in, gsl_vector_complex * out, flags); The idea would be for this api to support multiple implementations--in particular, the gsl_fft library and FFTW. These could be switched at compile time, runtime, or the implementation could be specified within the flags field of the constructor. The my_plan_t would be internally cast to a struct such as struct { int implementation; void * whatever;}; In the gsl_fft implementation, (*whatever) would point to a structure with the argument values for the correct gsl_fft call. In the FFTW implementation, the (*whatever) would be the real fftw_plan. The reason this is better than simply re-implementing the FFTW api using gsl to do the transforming, is that we'd like to extend the FFTW api to use gsl data types. > c) Would anyone be willing to help out (esp. with the vector/matrix > wrappers and with making these work for doubles and floats through those > GSL templates)? I'm supposed to be doing my master's thesis as well > (what I needed the DCT for in the first place) so it might take some > time to finish this on my own. 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 Check out libmsl at: http://www-etud.iro.umontreal.ca/~bergstrj/msl/html/index.html -- James Bergstra http://www-etud.iro.umontreal.ca/~bergstrj _______________________________________________ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl