Re: GSL, VSIPL, and the ultimate numerical library

["E. Robert Tisdale" <edwin at netwood dot net>]

Gerard Jungman wrote:

> One last point of emphasis,
> at the risk of repeating myself...
> 
> Because of the VSIPL goals,
> all of the discussion in the VSIPL/GSL thread
> has concentrated on linear algebra operations,
> and other large linear operations like FFTs.
> 
> Scanning the web for scientific software
> (a sad hobby of mine),
> you will find many projects
> (and many of these failed)
> which declare one of their main goals to be
> "to provide efficient and portable
> vector/matrix objects...".

You probably meant portable vector/matrix classes.
Objects don't exist until you actually run the program
so they can never be portable.

> Perhaps they also got as far as providing
> some kind of linear algebra,
> either native or through interfaces to lapack.
> 
> We can judge the success of these attempts
> by the fact that we are still arguing
> about vector/matrix implementations.
> 
> So I would just like to say that
> it is very important to draw a distinction
> between these "linear" parts of a generic library
> and the other functionality.  I'm glad that
> the GSL did not become one of these zombie projects,
> wandering in circles in the "vector/matrix" swamp.

We don't know that yet.  The GSL is not complete.
There is no reason to believe that the GSL
will survive any longer than the GNUSSL.

> On the other hand, it means that GSL could not afford
> to do anything substantial about these issues;
> we can't drain the swamp,
> and I doubt if it is even possible,
> given the limitations
> imposed by the implementation language.

Well, you can implement anything in ANSI C.
It's just harder to design a practical user interface
for ANSI C application programmers to use.

> And although VSIPL is a very reasonable spec in C,
> I think implementations will suffer
> from the standard abstraction penalties
> in generic situations.
> I don't think this is a controversial statement,
> but people are free to disagree.

Perhaps.  But it isn't ever necessary.
You can always implement specializations
to avoid any abstraction penalty.

> Also, the concentration on dense arrays
> is very limiting from the standpoint
> of general scientific computing.
> Maybe this will be addressed in later specs,

Maybe.
But meanwhile functions like gather and scatter
are meant to bridge the gap.

> but it looks like the standard combinatorial explosion
> of interfaces will be unavoidable.

Why should that bother you?
You're not an ANSI C compiler.

> These are the issues
> which I am most concerned with.
> 
> I optimistically hope that
> the brave new template world will come to the rescue.
> Right now, things are looking pretty good for that.
> Maybe we will finally be able to move on in life.
> I personally find linear algebra
> to be extremely tedious.

The problem with genericity in numerical computing is that
vector and matrix classes are NOT container classes.
Templates can help library developers implement
vector and matrix classes efficiently
but they require so many specializations that
they don't really help application programmers very much
in extending vector and matrix classes to new types.