This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl Development Query


Hi Group,

     Just a couple of comments from somebody who does not know very much
about gsl. I work on VSIPL and started lurking about to see how well gsl
and VSIPL will interface, since gsl is working on a lot of stuff VSIPL does
not do.

     Unlike gsl, VSIPL hides most stuff. We are a specification, not a
library. Implementations are free to implement blocks and views any way
they want as long as they meet the specification. Part of the specification
is the interface which allows people to bring data into or export data from
VSIPL.

     Now I have also been working on a VSIPL implementation, which is open
source, free and written in ANSI C, and available at the vsipl web site.
Long ago I needed an FFT and used FFTW in my implementation. Since the FFTW
copyright is too strong for the purposes of my implementation I just
encapsulated it and directed people to go to the FFTW site, get that
library, and then link it in when they built mine.

      The main problem with FFTW is they use an array of complex. Most of
the time an array of complex looks like interleaved complex (which is, I
think, what GSL uses for complex arrays). For the user interface VSIPL
supports both interleaved or split arrays (internally a complex block is
just a block of complex). However it is not "comfortable" just assuming
that the two will work together. So eventually I wrote my own FFT stuff
(which is pretty ugly since I don't know much about FFT's) just to make the
FFT fit better with the VSIPL spec. 

      I guess my point is you probably should have your own FFT's. It may
not be reasonable to make an interface to FFTW and keep the other
interfaces in your library coherent. Frequently the FFT speed is not that
important and, as long as your FFT speed is reasonable, it may be fine for
most peoples use. I assume your fft inputs and outputs will fit well with
other functions you have defined and this may be more important to your
users. If somebody really needs FFTW speed and also wants to use your
library then they should figure out how to make them interface. Hopefully
you give them enough information so they can do this. 

                  Randy Judd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]