This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: GSL 2.0 roadmap (one man's view)
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