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 >
