On 05/11/15 04:41, Patrick Alken wrote:
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?
I have used gsl_vector_long on occasion.
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
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.
Ruby? Python? In the absence of C++ templates I usually use one or
other. Python is likely more readable to C programmers.
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.
I’m happy to help if someone can suggest a basic workable design. I can
certainly change the alloc functions to use a pool allocator internally.
And, since I mostly use C++, I can see the logic of initialising vector
structs. But I can’t think of a good design that won’t break a lot of
user code. One of the features of the GSL is that you can’t alloc a
vector of size 0 without writing a custom allocator. It would be easy to
change gsl_vector_alloc. But I can’t even think how to do that and
guarantee not to break user code.
--
John D Lamb
