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

[Patrick Alken <alken@colorado.edu>]

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 ?

So to summarize:
   1. All GSL routines which currently take gsl_vector* arguments, 
should be modified to accept gsl_vector_view* instead
   2. gsl_vector_view should be redesigned to be cleaner/simpler <- I'm 
still not completely clear on what this would look like
   3. Ditto for gsl_matrix

Is this a correct assessment of what you're saying? If so, in principle 
I completely agree it can be burdensome on the user to constantly have 
to pass &view.vector, &view.matrix all the time. It would be nice to 
simply pass 'view' instead.

Patrick

On 11/03/2015 01:56 PM, Gerard Jungman wrote:
>
> The problem with the GSL containers is that the allocation
> strategy is hard-wired into the implementation. Adding
> another allocation strategy is not the answer, it just
> adds to the problem.
>
> Put another way, the real problem is that the GSL interfaces
> are written in terms of gsl_vector and gsl_matrix objects,
> which forces clients to carry along the allocation baggage
> whenever they want to use a GSL interface.
>
> The interfaces (every function that currently takes a
> const gsl_vector * for example) should be re-written in
> terms of a view type which is independent of allocation
> strategies. A view type should be basically a thin
> wrapper over a pointer and a length for vectors.
> For multi-array objects it would be a thin wrapper
> over a pointer with an addressing/indexing interface.
>
> The current "view" types are brain-damaged because
> they stand the design on its head. This is because
> they were added as an afterthought to the existing
> heap-allocated vector/matrix objects, at the time
> when this was all being implemented. Badly done.
>
> At the implementation level, the other main problem
> is the way the types are "composed" using indirections.
> This is awful and leads to the multiple allocations and
> other heap-centric lossage that has been discussed
> recently. Both views and full-fledged containers
> should be composed in a value-centric and
> stack-friendly way.
>
> And preferably in a way that allows them to interoperate
> and keep const-correctness. I believe this is all possible.
>
> -- 
> G. Jungman
>
>
> On 11/01/2015 02:00 PM, John D Lamb wrote:
>> On 26/10/15 15:13, Patrick Alken wrote:
>>>> Yes. I’d be happy to look at redesign of the GSL containers. What’s
>>>> needed?
>>>>
>>>
>>> There was a discussion on gsl-discuss some time back, see:
>>>
>>> https://www.sourceware.org/ml/gsl-discuss/2014-q2/
>>>
>>> Gerard may have already done some work on this, or have some ideas on a
>>> good starting point, so I suggest getting in touch with him too (cc'd).
>>
>>
>> I’d forgotten the detail of that discussion.
>>
>> I can think of a way to change the gsl block/vector/matrix alloc 
>> functions to be more efficient. In essence it is a pool allocator.
>> It would keep a record, for each power k of two up to some limit n, 
>> of the number of blocks allocated for sizes 2^k to 2^{k+1} together 
>> with a capacity (also a power of two) for blocks of that range. These 
>> would form linked lists of allocated and unallocated blocks. Given a 
>> request for a new block, if an unallocated one was available, it 
>> would be allocated. Otherwise the capacity would be doubled. When a 
>> block is freed, memory is only deallocated if no more than a quarter 
>> of capacity is used or if no blocks are used.
>>
>> This idea needs more input.
>>
>> I can’t think of a good way to create gsl_vectors and the like in 
>> stack memory. Of course, it is always possible to create a struct and 
>> initialise it.
>>
>> I also don’t know of a good, easy solution to the problem of constness.
>>
>