Re: gsl Development Query

[Gerard Jungman <jungman at lanl dot gov>]

Brian Gough wrote:
>
> For serious fft work we recommend using FFTW of course.

I agree. But isn't this an odd statement?
I really don't get it sometimes. If using FFTW
is the right thing to do, then why do we provide
our own implementation, with no explicit support for
connecting to outside implementations? This is the
worst of both worlds: tell people to use the other
thing, but don't provide any explicit way for them to
connect code using gsl abstractions to whatever
the external thing is.

And what exactly constitutes "serious work"?
Is GSL not for "serious work"?

There _should_ be gsl FFTs, for all dimensions,
but only in the sense that there should be
gsl defined _interfaces_ to such functionality.
These should be general enough to accomodate
any reasonable underlying implementation,
and should be a fixed target. It should be
possible for the user as well as the developer
to swap the underlying implementation at will.

Whether or not GSL itself provides a "native"
implementation is really a second order issue.
First design the interfaces, then connect them
to something that works (anything, to start),
and move on.

The same issue has arisen with the linear algebra
stuff. The world doesn't need another C implementation
of an FFT library any more than it needs another
implementation of BLAS and/or LAPACK, in any language.
I see now that the decision to provide a native GSL
implementation of linear algebra was probably a mistake.
I blame myself for that. But there is still time to
correct the problem there. Let's not make the same
mistake with FFTs.

If somebody wants to do something useful
(and we need all the help we can get), then
they should consider the following:

  1) We need a general definition of interfaces
     to FFT functionality, designed with GSL
     flavor, using GSL error reporting conventions,
     and probably paying at least some respect
     to the GSL data representations, conventions
     regarding stride, etc. This should be easy
     to do. All you have to do is look at available
     implementations, abstract out their common
     properties, and stir in a little GSL.

  2) We need a paradigm for connecting these GSL
     interfaces to external implementations. This
     must include the possibility of connecting
     to fortran implementations. Obviously, you
     should be able to connect to a "native"
     implementation as well (such as Brian's 1d
     implementation), if only as a fallback.

  3) Pick a default "example" implementation and
     make it as easy as possible for people writing
     GSL code to swap in that implementation. I tried
     to do this with BLAS by defining a set of GSL
     interfaces (the "gsl_blas_raw" interfaces) for
     wrapping external blas implementations and then
     providing a native implementation expressing
     those interfaces. However, maybe there is
     something wrong with this, since one of the
     most common messages on the mailing list is
     "what are all these undefined blas symbols?"
     People don't understand that they have been
     given the freedom to swap in any conformant
     implementation at link time, and so they
     have to choose. Frankly, I think some of
     the developers still don't get it (sigh),
     although it doesn't seem like such a bad
     idea to me.


>  > Q: Is there some kind of guide for developers?

By the way, I have been told that one of the
statements in the design document is something
about "no mixed language development". Some of the
developers seem to think that this implies we
should not provide interfaces to underlying
fortran implementations, and that we should
certainly not package up a wrapped fortran
implementation for distribution as a default
backend.

This sort of thinking is manifestly confused.
Is one of the design goals of GSL to waste
development time reimplementing perfectly
adequate and tested functionality from other
libraries? A fortran subroutine can be a
perfecty adequate tool for multiplying
matrices (after all, that is what fortran
does best).

Anyway, this issue of "mixed language"
support applies to the question of
how to provide linear algebra. But in
the case of FFTs, given the existence
of a high quality FFT implementation
in C (FFTW), I hope the correct path
is clear to all.


-- 
G. Jungman