> 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
