public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release
Date: Wed, 04 Nov 2015 23:06:00 -0000	[thread overview]
Message-ID: <563A8F65.1040706@lanl.gov> (raw)
In-Reply-To: <563A6C15.7080102@colorado.edu>

On 11/04/2015 01:35 PM, Patrick Alken wrote:
> Hi Gerard,
>
>   So if I understand correctly, restricting the discussion to 
> gsl_vector for now, the issue is that in order for users to use the 
> various GSL vector routines, they must first call gsl_vector_alloc, 
> and then copy their data into the gsl_vector object, and then use the 
> routine they want.
>
>   The better approach would be to define their vector array however 
> they wish, and then get a gsl_vector_view of that array (without 
> needing any GSL allocation routines), and then directly use the 
> routine they want. This is of course currently possible with 
> gsl_vector_view_array, however it would be better to pass the view 
> object directly to the GSL function, rather than having to pass 
> &view.vector ?

Yes. One of these is required.

But it's more than making the interfaces nicer. The current
design is upside-down. The view types are actually implemented
in terms of the alloced types. Strange, but true.

This leads to all sorts of bad design elements, like the
'owner' data element in the vectors. Why do vectors need
an 'owner' member? Apparently because they might actually
be part of a view and not own their data. This is just wrong.

Some users have reported on the mailing list that they get
around this mess by jamming a pointer and size into a
gsl_vector, setting 'owner' to zero, and getting on with
life. For these workarounds, the 'owner' flag is a lucky
circumstance. But this is clearly nuts. This need should
be filled by explicit support from the types and not
by hackery.

As part of a fix, the types should have much cleaner
and orthogonal relationships, and the interfaces
should not carry this implied dependency on the
semantics of the heap-allocated types, whether
people can get around it by hackery or not.

> So to summarize:
>   1. All GSL routines which currently take gsl_vector* arguments, 
> should be modified to accept gsl_vector_view* instead

But with a correctly designed thinner view type.

> 2. gsl_vector_view should be redesigned to be cleaner/simpler <- I'm 
> still not completely clear on what this would look like

Make the views the "fundamental" types and have the fat
types essentially inherit from (or export an interface for)
the non-const view types.

> 3. Ditto for gsl_matrix

And, while we are at it, multi-arrays too, which could be
provided with not much extra effort. Though, of course,
no current GSL interfaces depend on such things, since
they don't exist in the main code base yet.


Finally, the implementation of the fat container types
is also brain-damaged because of the "composition by
indirection" design. For example, gsl_vector and gsl_matrix
carry pointers to gsl_block. This leads to an unnecessary
chain of allocations, as has also been discussed recently
on the mailing list.

The compositions, to the extent they are needed, should
be more value-centric. Avoid these annoying indirections.

And the construction idiom for the fat containers should
be more value-centric. Returning gsl_vector indirectly
at construction is yet another unnecessary indirection
and heap allocation.

This obviously requires a complete re-design. But these
aspects of the work are not hard. It's not hard to get
these things right, it just requires some free time
and a willingness to break all the interfaces
that currently touch the containers.

--
G. Jungman

  reply	other threads:[~2015-11-04 23:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56293649.8010009@colorado.edu>
     [not found] ` <562BA530.7090508@johndlamb.net>
     [not found]   ` <562E432D.9050002@colorado.edu>
2015-11-01 21:00     ` John D Lamb
2015-11-03 20:56       ` Gerard Jungman
2015-11-04 20:35         ` Patrick Alken
2015-11-04 23:06           ` Gerard Jungman [this message]
2015-11-04 23:16             ` Patrick Alken
     [not found]               ` <563AB455.1020706@lanl.gov>
2015-11-05  4:41                 ` Patrick Alken
2015-11-07 14:09                   ` John D Lamb

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=563A8F65.1040706@lanl.gov \
    --to=jungman@lanl.gov \
    --cc=gsl-discuss@sourceware.org \
    /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).