Re: GSL, VSIPL, and the ultimate numerical library

[Randall Judd <judd at nosc dot mil>]

At 01:06 AM 11/02/2000 -0500, Robert W. Brewer wrote:


>The TASP VSIPL code is a pretty good choice, but it looks
>hard to maintain since there is so much code replication to
>support the different data types.  I recall an early version
>the Hughes VSIPL code which used a preprocessor template
>scheme that seemed pretty slick.  It looks like GSL has a
>similar problem, many functions are written 3 and 4 times
>just to support the different float and int types the user might want
>to instantiate.  And after all that, it still can't support
>neat things like arbitrary precision numbers, while a templating
>scheme might be able to.

It's not that hard to maintain, although there are some problems. I have 
found that templates tend to be more trouble than they are worth. Of course 
I am not a template or m4 expert.  M4 is what Bob was using. The time it 
takes to convert a float routine to a double routine is trivial. If I make 
major changes to a routine in float I usually just convert it wholesale 
instead of trying to change the double to match.

GSL and the TASP implementation of VSIPL are both trying to stay with ANSI 
C. I think writing routines which will support arbitrary precision would be 
difficult if not impossible, and of little use. VSIPL has the name space 
reserved for this precision but this was mostly to support any kind of chip 
precision at the native level. It was never fully developed and documented 
but the the idea of a vendor supplied tool (shell script) which would 
produce a header file to support particular precision of application code 
is supported in VSIPL.  If  the implementation did not support the users 
requested precision then the tool would fail (buy a library which supports 
your application precision requirements).


>To boil it down, the library I would like to use would be
>(most important first):
>    high performance
>    generic to allow optimizing under the hood
>       and advanced algorithms
>    templated for data type choices and easier maintenance
>    open source
>    easily tested for correctness with an automated suite
>
>I think the VSIPL API has a lot of good ideas for the
>functions that it supports, but the reference implementation
>would be easier to deal with if it were templatized.
>Maybe it's my personality, but making the same change
>in more than one place just wears me out.
The most important thing for VSIPL was portability. We want applications to 
run the same everywhere.

When you say "reference" I assume your talking about my implementation.

It would only easier to deal with if the person getting it understands and 
uses the same template scheme. What I go for is simplicity. This is mostly 
because I am kind of simple minded and frequently prefer a brut force 
method. But I see a lot of really nice code out there that I would never be 
able to figure out how to edit in this lifetime. There are things I would 
do differently (I am not as simple as I was when I started this project) if 
I was to start over. I am trying to work some of that stuff into my next 
release which should be out around January. One of them is to put all the 
source in a single directory so it is easier to build with tools like VC++.

The point I am trying to make here (not very well) is you can waste a lot 
of time trying to write something that lets a computer write your code for 
you. I find it is easier and surer to just do it the strait forward way.



>The GSL team has implemented a large breadth
>of functions, many of which have no equivalent in the VSIPL
>spec, but which could probably benefit from some of its principles.
>Since both the TASP reference implementation and
>GSL are open source, it might be possible to gradually
>combine them, as Randall Judd seems interested
>in doing.  Many GSL functions not present in VSIPL might
>be wrapped to present an interface similar to the VSIPL API.
>Then gradually the underlying GSL code could be moved into
>the wrapper to increase performance, better conform to
>VSIPL, etc.
I don't want to combine them. Just make sure they can work together.

>It might also be nice to go back to the
>technique in the Hughes code of implementing most of the
>functions in terms of other VSIPL/GSL functions or lower-level
>helper functions whenever possible.
I thought some of the stuff in Bobs code was neat, but almost none of the 
vendors liked it. It was also very (very, very,...) slow.  But VSIPL is a 
library specification, not an implementation. Anybody who is interested in 
doing some research in this area is more than welcome.


                                      Randy Judd