Aaron,

In the context of my question about external calls, you asked about the

relationship of the Gnu Scientific Library and Lapack. My impressions

are as follows - I'm copying this to pop-forum in case anyone else is

interested.

Both GSL ( http://www.*-*-*.com/ ) and Lapack (

http://www.*-*-*.com/ ) are freely available

numerical software packages. Lapack is also supplied by some

manufacturers - e.g. it's part of Sun's lib sunperf which comes as one

of the Solaris packages - and appears to be an industry standard. Both

seem well established and well supported, though GSL is more of a

community effort than Lapack.

Lapack does linear algebra only. GSL covers linear algebra but is far

broader in scope.

For linear algebra, Lapack is, I think, more "heavy-duty": the

algorithms are more carefully worked out and there is more generality

and support for special kinds of operations. The GSL manual contains the

following, at the start of the linear algebra chapter:

"[The GSL linear algebra functions] are intended for use with

'small' systems where simple algorithms are acceptable.

"Anyone interested in large systems will want to use the

sophisticated routines found in LAPACK. The fortran version of

LAPACK is recommended as the standard package for linear algebra."

I do not really know what this means in practice - specifically I don't

know what "large" means and how big the performance and accuracy

differences are for a given degree of "largeness". Empirical

investigation is needed - I expect someone has published a comparison

somewhere.

GSL is written in C and Lapack in Fortran. Fortran is probably a better

language for numerical computing, and its array storage scheme is a

better match to Pop-11's (which defaults to column-major[1]).

GSL supplies typedefs for its vector and matrix arguments. This means

that either programs have to be written with GSL in mind, or there has

to be a lot of work at the interface to wrap up ordinary arrays as GSL

structs. I want to be able to operate on ordinary arrays (a given

program might use lots of other packages too), so I'd have to provide

special interface tools for GSL. (By the way, the gsl_vector type does

not incorporate an offset for the first element, so I'd *still* have the

addressing problem that I've been asking about.)

Lapack takes information about matrix dimensions (which are contained in

the GSL structs) as separate arguments to the routines. This may be

viewed as old-fashioned and inelegant, but it's actually very convenient

if you want to make casual use of the library rather than build your

program round it.

Lapack explicitly uses BLAS (a standardised set of very low-level linear

algebra tools, which can be optimised for different platforms so that

higher-level code can be platform independent). GSL provides an

interface to BLAS, and I assume makes use of it for its own routines,

but I'm not entirely sure.

A comparison you didn't ask about, but might have, is with * VEC_MAT. I

have to admit I'm not happy about several aspects of VEC_MAT's design,

but one problem with it is its lack of Eigenvector/Eigenvalue and

Singular Value decompositions - the latter is what prompted me to look

around for something else.

The other obvious point of comparison is with NAg, which has tremendous

scope and quality, but which you have to buy.

I'm writing a Pop-11 interface to some of Lapack which I'll make public

when it's done. I might also have a go at an interface for GSL.

David

Footnote:

[1] Yes, the Poplog default is array-by-column. POPARRAY_BY_ROW is

misnamed and the documentation is all wrong - and always has been!