Re: GSL 2.0 roadmap (one man's view)

["Robert G. Brown" <rgb@phy.duke.edu>]

On Sun, 20 Sep 2009, Tuomo Keskitalo wrote:

> I agree that use of other libraries and even other languages with GSL should 
> be made as easy as possible. Data structures with dimension > 1 should be 
> explicit about the data being stored as "column-major" or "row-major".

I agree completely, and I further strongly suggest that a) the actual
data in any tensor form be stored in a single contiguous vector whose
address is available to the user and not hidden inside an opaque data
object; b) the tensor itself be a **...*pointer, cast to the desired
type, packed with the offsets into this vector; c) that the data should
be stored/packed using the same convention that C already uses to pack
e.g. v[i], m[i][j] declared data types.  Yes, this leaves one with the
perpetual conflict with e.g. fortran libraries, but GSL is a C library,
not a fortran library, and it should conform to the common usages and
standards of C and not try to interpolate to make fortran programmers
comfortable at the expense of C programmers.

My reasons for each suggestion are straightforward.  a) permits many
routines, e.g. ODE solvers, to be written for general purpose tensors by
letting them trivially directly access the vector data associated with
the tensor; b) allows the caller to use meaningful tensor notation to
evaluate functional forms throughout their code instead of using get or
set utilities to access particular elements of the tensor; c) makes the
code portable in critical ways -- it would be silly to have

for(i=0;i<imax;i++)
   for(j=0;j<jmax;j++)
      cmatrix[i][j] = gslmatrix[i][j];

(where cmatrix is a matrix allocated via e.g. double
cmatrix[imax][jmax] and gslmatrix is one created via the process
suggested above) do the wrong thing, and higher rank tensors should
obviously satisfy the same convention to make programming contractions
etc maximally simple.

Since MANY GSL routines could be affected by this -- in particular ODE
solution, linear algebra routines (if/when this is added),
multidimensional quadrature routines (ditto) -- the discussion should
occur at the very beginning.

    rgb

>
> -- 
> Tuomo.Keskitalo@iki.fi
> http://iki.fi/tuomo.keskitalo
>

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb@phy.duke.edu