Hello all,
An attempt to answer at least some of your questions:
On Wed, Mar 21, 2012 at 9:07 PM, Ted Byers <r.ted.by...@gmail.com> wrote:
> // I find the following distastefully wasteful. I would have preferred to
> have the GSL functions work directly on std::vectors instead
> // of having to allocate new memory and bear the cost of the loop and
> copying all the data. Indeed, I'd have hoped for expression
> // templates, to make these functions all the more efficient.
GSL was designed with C and never attempted to work well with
C++ vector types. In the case of STL vectors, you can use
gsl_vector_view_array (double * base, size_t n) and just set base
to the address of the first std::vector element. It might be possible
to make that work with matrices also, but in the code above it's
likely easier (and not that much slower) just to work with the
GSL vector types from the beginning, so you can make the call to
the SVD directly.
Even boost+STL is not immune from difficulties of this kind. The
way to do SVD within boost is to use ublas, but ublas vectors
aren't trivially compatible with STL vectors either (unless they
have the same size). This is why I always write my linear
algebra functions as template functions which accept any
reasonably formed vector and matrix types (but I don't have
SVD yet).
> I assume from your allocate and free family of functions that I can't create
> the vectors and matrices using operator new, and free them using operator
> delete, and thus give management of them to a smart pointer. How, then, do
> you manage to maintain exception safety?
There's no need for a smart pointer, you just have to check
the allocation of each vector separately and free up all of the
previously successful allocations in the case that one fails. Alternatively,
you can embed the vectors into a class, ensuring that the destructor
takes care of the deallocation in the usual way.
HTH,
Andrew
http://o2scl.sourceforge.net
