Re: GSL containers: was Re: [Help-gsl] Linear least squares, webpages and the next release

[Patrick Alken <alken@colorado.edu>]

I think this is a good idea. Would you be able/willing to design a new 
gsl_vector_view structure? Even something very preliminary which we 
could iterate a bit to get it to a nice mature status. I, or someone 
else, could then run with it and begin the tedious work of converting 
all the existing interfaces.

Patrick

On 11/04/2015 04:06 PM, Gerard Jungman wrote:
> 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
>