[Help-gsl] Re: Question: gsl in C++ ??

[Lionel B]

On Tue, 13 Mar 2007 16:07:24 -0600, Jordi Gutierrez Hermoso wrote:

> On 13/03/07, Jigal A <address@hidden> wrote:

[snip]

> Interesting. Lots of good ideas there, especially with memory
> management and handling of function pointers, both problems I've run
> into whilse writing my own C++ wrappers for the GSL. Hm, at a glance,
> my only complaint from what I see there is that they're indexing with
> operator[]. Not sure, but as I recall, this doesn't permit indexing
> such as a[1,2] since operator[] can only take one argument; the
> numeric community has a Fortran heritage of indexing with operator()
> instead which does allow more than one argument in C++

The other alternative is (C-friendly) [][]...[] indexing. There was a
very lengthy thread debating (,,..) vs. [][]...[] for matrix/array
indexing on comp.lang.c++ recently. My understanding is that you can
achieve the same functionality with either interface, although () is
probably easier to implement ([][]... requires some "proxy class"
tomfoolery). Personally as a (very ex)-Fortran programmer my vote would be
for () anyhow.

> (here's our chance to start indexing from 1 à la GNU Octave!)

No, please!

> We should also look into implementing gsl_vector with valarrays instead
> of direct memory manipulation, but this might break compatibility with
> BLAS.

I think valarrays are a good idea - relieves the burden of memory
management... and valarrays are completely BLAS-friendly too, I believe;
if you declare:

  std::valarray<double> v(N);

then &v[0] is guaranteed to point to a contiguous array of N doubles in
memory, which is just what the BLAS wants. Actually, the same holds for
std::vector, but the advantages of std::valarray over std::vector are that
(1) they are guaranteed not to be "aliased", which allows them to be
(potentially) better optimised by the compiler and (2) there is an
in-built mechanism for creating "slices" to implement multi-dimensional
arrays.

Cheers,

-- 
Lionel B