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

[Patrick Alken <alken at colorado dot edu>]

I agree that stuff is very confusing. I also wonder how much of it is
needed. In my work I've only ever used the double and complex versions
of gsl_vector/gsl_matrix. Most of the routines in GSL only work with
double vectors, with a few extended to complex double (linalg,eigen for
example).

Do we really need gsl_vector's for int/short/uint/long/etc?

On 11/04/2015 06:43 PM, Gerard Jungman wrote:
> On 11/04/2015 04:16 PM, Patrick Alken wrote:
>> 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
>
> The main practical problem is all the preprocessor "template"
> nonsense. I cannot think straight with all that junk hanging
> over everything. And I assume it would be impossible to have
> coherent discussions about it as well.
>
> I could make a reference implementation for a fixed type
> like 'double' and leave all the generalization to the very
> last step, once the design is entirely fixed. Of course, I
> would have to be careful about hidden assumptions which
> break for other types.
>
> If anybody can think of a better way to do the generalizations,
> besides the current preprocessor implementation, that would be
> great. I have nothing against the preprocessor, but the current
> framework makes it nearly impossible to actually read the code.
>
> The current impl is like traits classes, but where the traits
> are all defined in a very rudimentary way in "templates_on.h".
> It is impossible to tell what traits are available, which ones
> are required, and how the separate traits are associated with
> the basic types at the point where the macros are invoked.
>
> -- 
> G. Jungman
>