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

[Paulo Jabardo]

I use TNT extensively and I like it very much at least
as a container for arrays. Another alternative that is
much larger and much more complete is uBlas. It
provides interfaces using expression templates for all
sorts of matrices (full, sparse, etc) but I haven't
used it. Apparently it even includes bindings to
libraries such as atlas, lapack, umfpack and others.

As for math parser, I recommend using Lua. It is a
scripting language very well suited to embedding. As
far as scripting languages go it is very fast, very
small and easy to use and extend. I think it is better
solution than a simple math parser because
applications tend to grow and so do their needs and in
such cases lua is perfect.

Paulo Jabardo

--- Jigal A <address@hidden> escreveu:

> 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.
> _______________________________________________
> Help-gsl mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gsl
> 


__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/