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

[Jigal A]

TNT looks very tempting.
However - I thought of a combination of GSL and TNT.
GSL, after all, has a very large set of tools in many math disciplines.
I, for instance, needed the ODE and quadrature integration parts, and not
the BLAS part
(well, not explicitly, that is...).
The basic idea is to write something like TNT with the full set of features
given by GSL.

As for the math parser - surely there are alternatives on the net.
Also - GPL license for a GPL S/W is not that bad....

Best regards,
Jigal.



On 3/14/07, eknecronzontas <address@hidden> wrote:
> 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


--
Jigal A.