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

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

On Sun, 20 Sep 2009, Rhys Ulerich wrote:

>> 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
>
> Given both (a) and (b) everyone pays storage overhead for indexing
> twice.  The first time is to store the leading dimensions for (a)-like
> access, and the second time is to store the pointers-to-pointers for
> (b)-like access.
>
> Since (a) already exists today, if you want (b) it can be provided as
> a view.  Your cost will be storage overhead for pointers-to-pointers,
> dereferencing delay, and potential cache misses if the
> pointers-to-pointers for (b)-like access are far away from (a)'s data.
>
> I think those that want (b) should have a view that accomplishes it,
> but that people using (a) only shouldn't pay for the overhead.  I

I agree, which is why I suggest that a) always be directly and simply
available for people who are willing to write the somewhat ugly code (or
macros) required to dereference without the additional layer of
overhead and to facilitate other things such as ODE soolutions.

Bear in mind that code performance isn't always the primary issue, even
for numerical programs.  Sometimes ease of programming and/or debugging
are important, or the numerical task takes so little time that nobody
cares about the possibly small increase in execution time.  The
dereferencing code also gets pretty ugly and non-portable for
non-rectangular tensors of high rank with indices that don't always
start at 0.  Even if one's goal is to end up with a fast program with
inline dereferencing an minimal indexing overhead, it might well be VERY
USEFUL to have a direct and straightforward tensor view of the data
vector to use to write an easily debugged version that can in turn be
used to debug a fast version.

> believe these are the reasons that both the C and Fortran numerics
> communities pretty consistently stay towards (a)-like storage under
> the covers.
>
> Also, to be fair to the current design, gsl_matrix and gsl_vector are
> structs, but they certainly aren't opaque.

And they aren't extensible (or at least extended) to tensors of higher
rank.  Scalability matters.

    rgb

>
> - Rhys
>

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