This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: GSL
- To: "Jens Lenge" <lenge at hft dot e-technik dot uni-dortmund dot de>
- Subject: Re: GSL
- From: Brian Gough <bjg at network-theory dot co dot uk>
- Date: Mon, 27 Nov 2000 20:16:13 +0000 (GMT)
- Cc: <gsl-discuss at sources dot redhat dot com>
- References: <00af01c058a0$82f12fb0$2ebdd981@hades>
- Reply-To: gsl-discuss at sources dot redhat dot com
Hi,
I am one of the developers. Thanks for your questions, I will try to
answer them...
Jens Lenge writes:
> ==> Is it the goal of GSL to build a "native C" equivalent of LAPACK
> functionality?
We are trying to write a general scientific library which provides
similar functionality to existing fortran libraries. However, we
don't intend to rewrite LAPACK because it is (a) huge and (b) of high
quality, so we could not improve on it. We recommend using LAPACK for
large problems.
We have provided some simpler routines for linear algebra, similar to
those found in Numerical Recipes. These allow people to avoid
installing LAPACK if they only need to solve a small linear algebra
problem.
> ==> Will it depend on (or include) an underlying BLAS library?
Yes. We use blas internally in the library.
> ==> If so, is that BLAS also native C?
Yes, we have one (partly written -- we still need to write a Level-3
BLAS). We have a facility for substituting other BLAS libraries
(provided they conform to the Cblas standard).
> ==> Who is actually doing GSL? Is Redhat involved?
There is a list of developers in the AUTHORS file of the distribution,
also accessible from the website http://sources.redhat.com/gsl/
Redhat is not directly involved in the development, but they provide
the hosting for the CVS access and website (much appreciated).
> ==> 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?
Our complex data type struct is { double d[2]; } where d[0] = real
part, d[1] = imag part. This is compatible with most complex
datatypes in practice, e.g. {double re; double im}. All the complex
number access is through macros so it is possible to recompile the
library with a different definition of complex if desired.
We have a design document gsl-design.texi which is in the doc/
directory of the gsl-0.7 tar file.
If you have any more questions feel free to ask.
regards
Brian Gough