Hello!
In regards to Jordi's message about indexing with operator[]:
> 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++ (here's our
> chance to start indexing from 1 à la GNU Octave!) We should also look
> into implementing gsl_vector with valarrays instead of direct memory
> manipulation, but this might break compatibility with BLAS.
I use operator[] because it allows me to use C-style arrays, which
are faster, and can be easier to optimize with for the compiler. Because of
this, some of the Hal versions of the GSL routines can be faster than their
GSL progenitors (when they are written correctly). I have tested this for a
few particular cases, but some things are missing. (This also means I need
to have separate template types for the array allocation, which is a bit
confusing at first glance.) The situation for 2-d or higher-d arrays is more
complicated...
If you're not constrained to the GSL structure, then there are C++ ish
alternatives that have already been created (e.g. the template numerical
toolkit aka TNT).
Take care,
Andrew