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

[Rhys Ulerich <rhys.ulerich@gmail.com>]

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

- Rhys