This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
questions about block/vector/matrix
- From: Gerard Jungman <jungman at cybermesa dot com>
- To: gsl-discuss at sourceware dot org
- Date: Sun, 04 Oct 2009 20:03:16 -0600
- Subject: questions about block/vector/matrix
** Specific questions/comments about blocks, vectors, matrices.
Q1. Why do the vector and matrix structs have a block member at all?
At first I thought it was using some block functions in the
implementation (like for i/o), but it is not. The block
member seems pointless. See the following question.
Furthermore, from the standpoint of object design, the vector
concept does not inherit from the block concept, since a vector
is strided and a block is not. They are incompatible concepts.
If blocks have no semantic reason to be in vectors, and if
they are not used in a integral way in the implmentation,
then they should be removed.
Q2. What is the meaning of functions gsl_vector_alloc_from_block(),
gsl_vector_alloc_from_vector(), etc.?
gsl_vector_alloc_from_block() seems to be constructing a view of
an underlying data segment. As such, it conflicts with the
semantics of views. There should be only one view semantic.
Also, it generates a needless coupling between the block
component and the vector component.
gsl_vector_alloc_from_vector() is similar, though it is more
appropriate to say it is constructing a slice of a vector.
Again, the semantics are confused.
The suffix '_alloc' is confusing, since it is not clear what is
being alloced. Obviously the struct itself is being alloced, since
it is returned by pointer. But what about the data?
The same questions and comments apply to the functions
gsl_matrix_alloc_from_block(), gsl_matrix_alloc_from_matrix(),
gsl_vector_alloc_row_from_matrix(),
gsl_vector_alloc_col_from_matrix().
Q3. Why do we have functions like gsl_matrix_row(),
gsl_matrix_diagonal(), etc,
and yet no support for general slicing operations? These functions
should
be simple wrappers over a more general functionality.
Q4. Why do views export a different interface?
There are many operations on vectors that I cannot apply to vector
views, but which would make perfect sense for views. These include
obvious things like min(). max(), scale(), etc. They also include
the i/o functions. Writing and reading from and to view objects is
a perfectly well-defined notion.
The view design lacks any notion of genericity, lacks coherence,
and is essentially useless as it stands.
Q5. How many people use gsl_vector_uchar.h? Or gsl_vector_short.h?
Or gsl_matrix_ushort.h? Etc. Just curious.
** Recommendations for block/vector/matrix
R1. Remove the view types.
R2. Redesign vector and matrix so that they subsume the view concept.
R3. Decouple vector and matrix from the block component.
These changes can be done in a source-code compatible way, by
creating a type equivalence between views and the underlying
type and retaining the current view function interfaces
(with new implementations and marked as deprecated).
R4. Make explicit the vector and matrix semantics. This is more
a documentation/design goal than a code goal. See my
tentative design summary elsewhere.
** Recommendations for a multi_array functionality
R5. Create a parallel container component (tentatively
gsl_marray_...),
which supports arbitrary rank indexed views of data segments.
Support a general model for slicing.
R6. Create simple wrappers which allow viewing multi-arrays of the
approriate shape as vectors or matrices and vice-versa. There are
semantic constraints which prevent a multi-array from "being"
a vector or matrix, so there will always be distinct types.
Technical issue: Figure out how to do this without creating a
cross-coupling dependency between the components. i.e. make
sure the design is levelized.
** Recommended further steps
R7. Implement generic slicing for vectors, using the model from
the new gsl_marray. This is not difficult since slicing
vectors has limited semantics.
R8. Implement generic slicing of matrices, using the model from
the new gsl_marray. A slice of a matrix may not necessarily
"be" a matrix, even it looks like a sub-matrix. Semantic
constraints will need to be expressed and enforced.
** Status
I have begun most of these steps myself, in an attempt to sort out
the requirements and work through different designs.
R1, R2, R3: I have begun this process, on a private branch.
Currently waiting for some answers/discussion
regarding the questions above.
R4: Done as part of tentative design.
R5: Mostly done.
R6, R7, R8: Not started. Awaiting R1-R3.