help-gsl
[Top][All Lists]
Advanced

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

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


From: James Bergstra
Subject: Re: [Help-gsl] 2d FFTs, DCTs, etc.
Date: Thu, 11 May 2006 13:01:43 -0400
User-agent: Mutt/1.4.2.1i

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





reply via email to

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