This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]