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]

Re: gsl container designs


Hi,

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..

--
Tuomo.Keskitalo@iki.fi
http://iki.fi/tuomo.keskitalo


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