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 Development Query


Randall Judd wrote:

> The Core, and Core Lite documents are what are called profiles.
> No vendor, except perhaps SKY, has completed all of VSIPL yet.
> But they wanted to be able to say they are VSIPL compliant.
> So we defined profiles to give them a starting point
> and a way to claim compliance to something.
> Core Lite is only about 129 function
> and is a very easy starting point for most vendors.
> A great many, surprisingly so, current Navy applications
> appear to be mappable to just a core lite implementation.
> The core profile has about 500 or so functions
> and include more complicated things.
> In the future, there may be more profiles.
> A profile is basically a defined set of functions
> that has been approved by the VSIPL forum.

It is important to distinguish between
what a standard specifies and what it mandates.
The problem with the BLAS library API standard, for example,
is that it mandates everything that it specifies.
You can't implement part of the BLAS library API standard and
say that you have implemented the BLAS library API standard.
Somebody would get upset and accuse you of fraud.
The BLAS library API standard designers couldn't get
BLAS library developers to implement everything
that they wanted in the BLAS library API standard
so they compromised.  They left out a lot of functionality.
The result was a much impoverished API design
from the numerical application programmers point of view.
You can check this out by reading
"A Set of Level 3 Basic Linear Algebra Subprograms,"
by Jack Dongarra, Jeremy Croz, Iain Duff and Sven Hammarling,
Section 8 Rationale which you can download
as a PostScript file blas3-paper.ps from

	http://www.netlib.org/blas/

The VSIPL profiles decouple specifications from mandates.
They "partition" the VSIPL library into manageable chunks
which depend upon each other in a natural way.
Matrix objects depend upon vector objects,
linear algebra depends upon matrix objects,
tensor objects depend upon matrix objects, etc.
so library developers can build a complete VSIPL library
in increments over time.

Still, the VSIPL API standard is limited in scope.
The vector part includes some linear algebra
but it is mainly intended for digital signal processing.
Eventually, it is supposed to include
digital image processing as well.
It was never really intended to be
a general purpose Scientific Computing library
as I (and Randy I suppose) hoped the GSL was supposed to be.

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