This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GSL Error Handling


Brian Gough wrote:

> The appropriate procedure for copying subvectors in GSL
> is to create a corresponding subvector view
> then copy from that to the destination.
> This shows explicitly that only part of the vector should be copied.
> It is analogous to using an explicit cast in an assignment.

I agree!
Insisting that the vector views must be the same length
will encourage numerical application programmers
to write code that others can read, understand and maintain.
Still, I think that the GSL documentation should state that
the result (the contents of the destination vector) are UNDEFINED
if vector views of different length are passed
to the GSL vector copy function.

> The behavior of GSL's vectors is based on the C++ valarray model
> where copying valarrays of different lengths by assignment
> gives undefined results (i.e. an error).

Yes.
But valarray does NOT return an error code.

It might be a good idea for GSL library functions
to return an error code
or implement some other error handling mechanism
when it isn't practical for the application programmer
to detect the problem before calling the function.
Some sort of error handling is essential, I think,
for functions that compute a matrix inverse, for example.
But the GSL is a relatively low level library
and it should, whenever possible, avoid functions
that require error and/exception handling.
It is relatively easy for application programmers
to check the result of a matrix decomposition,
for example, before they try to solve
a system of equations.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]