Re: gsl container designs

[Gerard Jungman <jungman@lanl.gov>]

On Wed, 2010-01-06 at 10:47 -0500, Robert G. Brown wrote:

First, I want to say that I agree with everything you
say. These are exactly the problems that we need to solve.


> IMO the primary reason for "fixing" vector/matrix objects in the GSL is
> to enable the single vector that represents the actual data in the
> object to be presented to the user in a matrix-intuitive way, even at
> some cost in code efficiency (and to try to minimize that cost or
> provide further benefits to counterbalance it by enabling efficient
> linear algebra routines to be matched to it, for example).

In fact, I don't even see a need to sacrifice efficiency. I think 
this goal is directly achievable at essentially optimal efficiency.
My attitude about C is that it is all about lining up the bytes.
A good C design is just some syntactic layer on top of a
rudimentary layer, where-in you are careful to line up all
the bytes. After that, optimal efficiency is pretty much
automatic. C is very friendly, once you are careful to
line everything up. I hope you see my small but non-vacuous
technical meaning.


> What I want is extremely simple:
> 
> * A way to construct/allocate a matrix of arbitrary dimension (out to some
> (un)reasonable max, e.g. 10

Check.


> but I want to be able to use it
> just like m[i][j][k]...[r][s] when all is said and done.

This is the only part which I wonder about. I thought about this
before and came to the conclusion that it is not easy to get right.
Probably possible, but very tricky.

The most annoying aspect of this is that these little problems
are trivial in C++. But maybe just beyond the capability of C.


> * The specific dimension bounds need to be user specified.  If I want to
> make a 6 dimensional triple triangular array to hold e.g. 3j symbols, I
> don't want to have to allocate a rectangular array most of which is
> empty wasted space.

See the earlier comment by Tuomo Keskitalo, about banded/packed storage.
Not something I have thought about yet, but probably not hard.


> * Access to the underlying actual data vector (non-opaque, in other
> words) so it can be passed to e.g. ODE solvers and the like that can
> only be sensibly written in a general way for a vector.

Check.


> My problem in this regard with the GSL is that so far, the matrix and
> vector constructs are pretty much useless -- they are far away from the
> standard way one usually does this sort of thing in C using pointers or
> just allocating a vector or matrix.

I find them useless as well, for exactly these reasons.


> One of the ADVANTAGES of C is that it permits one to work pointer magic
> to improve the readability (and sometimes execution efficiency) of code.
> Opaque types and set/get calls are dark evil in both regards.

Right. The layer which defines the "types" should be essentially
syntactic, just there to make it easier to organize/understand
your code. The underlying implementation should be a brutally
simple pile of bytes, and it should be visible.


--
G. Jungman