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

[eknecronzontas]

Hello!

     Hopefully this is all of sufficient general interest to continue posting 
to help-gsl....

    Since we're talking about C++ array types, in addition to TNT I also ought 
to mention Blitz++. In regards to speed, Blitz is the one to compete with. 

     In regards to the FunctionParser class, check out the original webpage (I 
think http://warp.povusers.org/FunctionParser/) because the licensing has 
changed over time. In any case I agree w/you the licensing is problematic. I'll 
have to check out lua. 

In direct response to Jordi's message:
     1) "your (?) code" - yes...it's mine.
     2) Keep me posted on what you're doing if you wouldn't mind...
     3) I'm still not convinced valarrays are faster. C-style arrays can be 
used to do stack-based arithmetic, which is naturally faster than arrays 
allocated on the heap?

Take care,
Andrew

----- Original Message ----
From: Jordi Gutierrez Hermoso <address@hidden>
To: eknecronzontas <address@hidden>
Cc: address@hidden; Jigal A <address@hidden>
Sent: Wednesday, March 14, 2007 2:09:14 AM
Subject: Re: [Help-gsl] Question: gsl in C++ ??

On 13/03/07, eknecronzontas <address@hidden> wrote:
> I use operator[] because it allows me to use C-style arrays, which are faster,

I have not looked at your code, so perhaps I should do that before I
comment on it, but I can tell you one thing: there are few valid
reasons to use C-like arrays in C++ and speed is certainly not one of
them, especially not for numerical computations. The C++ standard
requires valarrays to be as optimised as possible, and I trust that
the GNU implementation of valarrays satisfies these requirements (but
if I'm wrong, please correct me). It might even be possible to
implement gaxpy and saxpy operations with valarrays without using the
BLAS interface; indeed, code with valarrays is intended precisely for
vectorisation on specialised hardware where the compiler is allowed as
many optimisations as possible.

Down with "C++ classes and constructs are slow" beliefs! :D

> The situation for 2-d or higher-d arrays is more complicated...

Another case for valarrays and slices! Slicing valarrays seems to me
like a rather straightforward method for creating 2-d or N-d arrays.

> 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).

Another library I haven't looked into. Hm, if I'm going to be putting
together a proposal for Google's summer of code, I'd better be aware
of these alternatives. Thank you for pointing it out.

Also, I was looking at the license for the FunctionParser class, which
isn't GPLed and seems to insinuate that GPLed code cannot be
commercial. The license is certainly not DFSG-free, since it restricts
commercial use, which is usually my own lowest criterion for
determining the freeness of code. The license certainly isn't written
in proper legal terms, and saying "it's free, period" doesn't clarfiy
much of anything, especially since "free" doesn't have a legal meaning
I'm aware of.

I think I would prefer to avoid using this class unless the author
agrees to change licensing terms. I may contact the author about this
if I intend to use this class and your (?) code as a basis for
creating the rest of a C++ numerical library based on the GSL.

Cheers,
- Jordi G. H.