public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Tuomo Keskitalo <Tuomo.Keskitalo@iki.fi>
To: Brian Gough <bjg@gnu.org>
Cc: Gerard Jungman <jungman@lanl.gov>,
	 GSL Discuss Mailing List <gsl-discuss@sourceware.org>
Subject: Re: gsl container designs
Date: Wed, 06 Jan 2010 11:45:00 -0000	[thread overview]
Message-ID: <4B4477B8.50305@iki.fi> (raw)
In-Reply-To: <m3fx7q4mdr.wl%bjg@network-theory.co.uk>

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

  parent reply	other threads:[~2010-01-06 11:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25  0:55 Gerard Jungman
2009-11-29 21:04 ` Brian Gough
2009-12-04 18:48 ` Brian Gough
2009-12-09 21:04   ` using GSL with C++ (was Re: gsl container designs) James Amundson
2009-12-09 21:14     ` Jochen Küpper
2009-12-09 21:54     ` Jari Häkkinen
2009-12-10 11:46     ` Brian Gough
2009-12-10 12:09       ` Brian Gough
2009-12-10 13:42     ` Robert G. Brown
2009-12-10 21:44       ` James Bergstra
2009-12-10 15:15     ` Kevin H. Hobbs
2010-01-06 11:45   ` Tuomo Keskitalo [this message]
2010-01-06 15:47     ` gsl container designs Robert G. Brown
2010-01-07  1:50       ` Gerard Jungman
2010-01-07  3:29         ` Robert G. Brown
     [not found]           ` <4a00655d1001062110m139c0a8tf2eae7de67da8f6f@mail.gmail.com>
2010-01-07  5:46             ` Rhys Ulerich
2010-01-07 13:22               ` Robert G. Brown
2010-01-08 20:08           ` Gerard Jungman
2010-01-07 18:29     ` Brian Gough
2010-01-06 12:04 ` Tuomo Keskitalo
2010-01-06 19:57   ` Gerard Jungman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B4477B8.50305@iki.fi \
    --to=tuomo.keskitalo@iki.fi \
    --cc=bjg@gnu.org \
    --cc=gsl-discuss@sourceware.org \
    --cc=jungman@lanl.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).