This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]