Re: GSL API design flaws

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

James Amundson wrote:

> A great deal of work went in to the design of GSL.
> Unfortunately, very little of it has been discussed on this list.
> Even less appears in the documentation.
> Please don't be fooled into thinking that
> a bunch of mindless drones are re-typing Numerical Recipes.
> The GSL authors have worked much harder than that.

Hard work is a necessary but not sufficient condition
for a good numerical class library API design.

> If you would like to better understand the design decisions in GSL,
> the easiest way to learn is to ask questions on this list.

Who is supposed to use the GSL?
Numerical class library developers?
Or numerical application programmers?
Amateur numerical application programmers
who write code for their own use?
Or professional numerical application programmers
who write code for other people to use?
Mathematicians, scientists and engineers
who use the existing API to write application programs?
Or computer scientists who write their own wrappers
around the GSL API.

Why does the GSL exist?
Is it just a low cost alternative to existing numerical libraries?
Or is it supposed to contribute to "the state of the art"
in numerical computing somehow?
Why didn't you just implement an existing standard API?
Why would numerical application programmers
choose the GSL over other numerical class libraries?

Can I write my own proprietary version of the GSL,
copyright it and distribute it for profit
without disclosing any of my source code?
Who pays for the development and maintenance of the GSL?
Is all of the work being done by volunteers?
Who provides support for the GSL?
If something breaks, do I have to fix it myself?
Or do I have to wait until a volunteer can fix it for me?

Was the GSL designed from the top down
starting with a clear description of the API
then designing the implementation around it?
Or was the GSL designed from the bottom up
designing the API around the implementation?

Precisely what Abstract Data Type (ADT) does the GSL API support?
I can't find a concise definition anywhere in the documentation.
The ADT appears to support

    strided real and complex multidimensional views
    of one dimensional arrays of real numbers

except that it appears to be restricted to
one dimensional arrays of at least one element,
vector and matrix views, positive strides,
and unit stride down the rows of matrix views.
What are the reasons for each of these restrictions?

What language bindings does the GSL API support?
It appears that the GSL API supports only ANSI C.

Which computer architectures does the API support?
Since it is always possible to obtain a pointer to the base type,
I don't think the GSL will support multiple memory spaces
like you find on Digital Signal Processing (DSP) chips
any multiprocessor systems with private local memory.

Why doesn't the GSL API hide
the actual data representation for vector and matrix views?
Once application programmers begin to use and depend upon
the GSL API, it will be practically impossible
to change the data representation without changing
all of the existing application source code.

Why doesn't the GSL API use the function naming conventions
supported by standard vector and matrix class libraries?

Why doesn't the GSL API support a full complement
of vector and matrix class arithmetic operations
like the gsl_complex number classes do?

> If you think you think you have found simple solutions
> to the hard problems posed in designing a numerical library,
> you haven't thought about it hard enough yet.

I don't have simple solutions for all of your problems
but the GSL API design contains obvious flaws
for which there are well known solutions.
Much of the functionality, which most numerical application
programmers expect, is missing.
There are no regular rules and too many exceptions
and special cases for application programmers to remember.

Take a look at
the Vector, Signal and Image Processing Library (VSIPL)
API standard at

    http://www.vsipl.org/

The VSIPL API is very similar to the GSL API
and a lot of really smart people
have been working very hard for a long time on it as well.
Maybe they can learn from you.
They invite comment and criticism at their web site.
You might be able to learn something from them as well.
I don't know.  Maybe I'm wrong.