Re: gsl_vector_subvector

["E. Robert Tisdale" <edwin at netwood dot net>]

Brian Gough wrote:

> I will correct that to v->offset.

You probably meant to change it to

     v'(i) = v-->data[i*v->stride]

GSL vector objects don't have an offset.
The offset from the beginning of the block
is already incorporated into pointer data.

It doesn't matter that you access the data members directly
in your implementation of the GSL.
You can rewrite all of your GSL code
if you decide to change the data representation.
But you shouldn't expose the gsl_vector type definition
to GSL application programmers.
You won't be able to change any of their code
if they decide to access the data members directly.
You REALLY need to provide GSL functions,
inline functions or C preprocessor macros
that application programmers can use instead
to access the data members.  Then, if you decide that
you need to change the data representation,
you can just distribute new function definitions
along with the new gsl_vector type definition and all will be well.

> The GSL convention is to return pointers
> for objects allocated on the heap (in the style of malloc/free).
> The functions which return an object on the stack
> are intended for temporary views.
> This allows a stylistic distinction to be made
> within a function between views defined in the local scope
> and vectors passed as arguments (pointers).

That's a very weak argument.
Right now, nothing prevents application programmers
from defining their own GSL functions to create gsl_vector objects
either on the stack or on the heap as I have done.
You should either hide the gsl_vector type definition
or you should provide GSL functions
to do all of these things for them.
Of course, I'm just speculating that
GSL functions will be more reliable if you implement them
than they would be if all application programmers
are obliged to implement them for themselves.