gsl container designs

Tuomo Keskitalo
Wed Jan 6 11:45:00 GMT 2010


On 12/04/2009 08:36 PM, Brian Gough wrote:

> At Tue, 24 Nov 2009 17:54:46 -0700,
> Gerard Jungman wrote:
>> Here are header files for a couple different approaches to containers.
>> I didn't bother with any implementations; it seems obvious how to
>> implement most of these functions.
>> The designs are not complete, but they express most of
>> the important stuff.
> Thanks for the document, I have studied the designs this week.  It
> seems that changing to design 1 / 1u / 2 would be trading one set of
> problems for another.  Looking at each case, the change doesn't seem
> sufficient to justify the compatibility cost.

Do you mean the compatibility to GSL 1 types by the compatibility cost? 
When talking about GSL 2 I don't think we should give too much value to 
maintaining backwards compatibility. GSL 1 is not going to cease to 
exist, and people who have tied themselves deeply to GSL 1 data 
structures can continue to use it.

> 3) Non-levelised types.  These seem to be the price for type safety.
> In terms of the look/feel, expressions like &row.vector and
> &column.vector don't seem too unnatural to me.

Here is a crazy idea: If we take Gerards design 1, would it be too 
absurd to use a horrible big wrapper struct like

typedef struct {
   gsl_marray *m;
   gsl_const_marray *cm;
   gsl_marray_1 *m1;
   gsl_const_marray_1 *cm1;
   gsl_marray_2 *m2;
   gsl_const_marray_2 *cm2;
   gsl_marray_3 *m3;
   gsl_const_marray_3 *cm3;
   gsl_vector *vec;
   gsl_const_vector *cvec;
   gsl_matrix *mat;
   gsl_const_matrix *cmat;
} gsl_container;

and make everything a gsl_container, and then always use them like
&a.mat or &b.vec? Maybe the const types could be in another 
gsl_const_container struct..

One downside is that this would effectively mask the type of a or b in 
program code (gsl_container a; // is it a vector, matrix, or marray?), 
which might make reading code a pain..


More information about the Gsl-discuss mailing list