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



Hi.

Jens Lenge wrote:
>
> GSL is often said to become a complete rewrite of LAPACK in native C, thus
> offering LAPACK functionality without depending on F2C or any underlying
> FORTRAN libs (like CLAPACK does).

Hmmm...


> ==> Is it the goal of GSL to build a "native C" equivalent of LAPACK
> functionality?

No. That would be too much. And we really don't see the
point, for several reasons. First, if what you want is
a C interface to LAPACK, then CLAPACK is probably more
appropriate. Second, effort on new native implementations
of this sort of thing would be better spent on C++, where
a lot of recent work has made great progress.

GSL has a native vector/matrix implementation, and it
would be really good to have a LAPACK interface for
working with these containers. But it could be only
a wrapper over CLAPACK. The amount of work required
in reimplementing LAPACK makes the idea insane.


> ==> Will it depend on (or include) an underlying BLAS library?

In my view, it should depend on a layer over a BLAS implementation.
The feature of the GSL work is that it is really just a layer
over a BLAS implementation, so in principle you can plug in
any implementation you like. The fact that GSL also comes
with a (incomplete) BLAS implementation of its own, I consider
to be of secondary importance.


> ==> If so, is that BLAS also native C?

As mentioned above, there is an incomplete native C BLAS
included in GSL. I wrote it. I think it was a bad idea,
but I was swayed by all the talk about having a "clean",
"new", "native C" implementation. Well, it's "new" anyway,
and it is written in C ...


> ==> Who is actually doing GSL? Is Redhat involved?

There is a link to the AUTHORS file on the web page, where
you will find all those people who have contributed substantial
code to the project. However, it's fair to say that the bulk of
the work has been done by Brian Gough and me.


> ==> When used as a basis for a C++ wrapper lib, will the GSL data structures
> be compatible with STL containers or the C++ complex<double> class?

Well, that is a good question. The last time we looked at it, the
C++ standard did not guarantee that a container of this type would
necessarily be associated with consecutive "packed" locations.
However, C and fortran arrays are always packed, so there is a
possibility that some implementations would be inconsistent.
In particular, it's not clear if you will always be able to
feed a C++ container to something like a legacy (or even "new" native C)
BLAS implementation. This may be what you were thinking about.

I don't think there is very much we can do about that.
No matter what you do, making an STL library implementation
talk to legacy codes will always require exposing some
detail of the STL implementation.

On the other hand, using STL containers for numerical
arrays is probably a bad idea anyway. That's why the
C++ standard includes valarray. Unfortunately, the
concensus seems to be that valarray is broken and
will never really work right (see discussions on the
mailing list at oonumerics.org). That leaves only
nonstandard implementations. But the state of the art
in nonstandard implementations is quite high. See
http://www.lsc.nd.edu/research/mtl/ for example.

In the end, you probably want to use STL for
one or more of the following reasons:

  1) standard, therefore portable and easy to use
  2) ready-made containers
  3) ready-made algorithms

If you use a third-party library, like MTL, you get
ready-made containers, so (2) is taken care of. If the
library containers are generic enough (MTL containers are),
then you get to use the STL algorithms that make sense.
That's the point of genericity, so you pretty much get (3)
for free too. That leaves (1), which is the sticky part.
With luck, genericity buys you a significant part
of (1) as well. But there will always the problem
of obtaining, building, installing, and tracking
for third-party products. Thankfully, it is not
too difficult when the authors show some
concern for these things.


Hope that answers your questions.
Thanks.

-- 
G. Jungman

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