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 containers: was Re: [Help-gsl] Linear least squares, webpages and the next release


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


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