Re: gsl Development Query

[Randall Judd <judd at nosc dot mil>]

I guess I don't know if Bobs comments belongs on this discussion group
since it does not talk very much about GSL but their are a couple of
corrections I would like to make.

First a comment. GSL keeps everything out front. VSIPL hides everything. If
I was doing GSL I very well might write my own support functions. By that I
mean I don't have to make a GSL block using a GSL funciton. I could just do
gsl_block a_block;
double data[100]
a_block.data = data;
a_block.size = 100;

You can not do this in VSIPL. So part of the job of a profile is to make
sure all the correct support functions are included to handle all the
functions you want to do. 

>
>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,
This is wrong. Matrix objects stand alone and do not depend on vector objects.

>linear algebra depends upon matrix objects,

Dito for tensors.
>tensor objects depend upon matrix objects, etc.
>so library developers can build a complete VSIPL library
>in increments over time.
>

Don't know what the following means. We defined some functions. We left a
lot out. We still have a lot of functions defined. 

I think one of the main differences between VSIPL and GSL is it is easier
to add new functionality to GSL. If somebody gives you a well written
function following the rules as set out by your forum you would probably
just add it in. I expect you are not so much concerned with adding new
functions, it's writing them to start with. With VSIPL it is convincing
vendors that they should all write this function so they are not likely to
put one in just because somebody has written it already. To get new
functionality into VSIPL requires a lot of work, and I don't mean programing.

>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.

I actually don't have any hopes for GSL except I hope you succeed in your
efforts. It sounds like a lot of work, and I know because I still have a
lot of work to do on my VSIPL implementation. My main concern for GSL is
some API inconsistency. For instance shouldn't

gsl_fft_complex_radix2_forward(gsl_complex_packed_array *data,size_t
stride, size_t n)

have some sort of vector input? I am not sure why you did it this way. Note
that I don't really know all that much about your library. But I get the
feeling that every programer is defining his own interface. You may end up
with a lot of nice functions but they won't fit together very well and will
be hard to program with.

                      Randy Judd