From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerard Jungman To: Jens Lenge Cc: gsl-discuss@sources.redhat.com Subject: Re: GSL Date: Mon, 27 Nov 2000 12:20:00 -0000 Message-id: <3A22C1DF.E399AB76@lanl.gov> References: <00af01c058a0$82f12fb0$2ebdd981@hades> X-SW-Source: 2000/msg00633.html 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 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