From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23614 invoked by alias); 5 Oct 2009 10:12:18 -0000 Received: (qmail 32765 invoked by uid 22791); 5 Oct 2009 02:01:52 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Subject: questions about block/vector/matrix From: Gerard Jungman To: gsl-discuss@sourceware.org Content-Type: text/plain Date: Mon, 05 Oct 2009 10:12:00 -0000 Message-Id: <1254708196.18519.1.camel@ForbiddenPlanet> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00000.txt.bz2 ** 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.