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
next prev 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).