Re: [Help-gsl] Re: gsl c++ wrapper ?

[Rohit Garg]

On Sun, Sep 6, 2009 at 8:59 PM, Hongzheng Wang <address@hidden> wrote:
> If I really need a C++ style vector/matrix library, I would refer to
> boost uBlas + bindings.  But for daily normal numerical work I
> encountered, gsl is easily used and better because vector/matrix
> support is not the whole world; we usually need more numerical
> computation facilities beyond basic vector/matrix support and gsl is
> such a quite complete solution.

Well,  you can of course use ublas and the like, but  after looking at
these benchmarks,

http://eigen.tuxfamily.org/index.php?title=Benchmark-August2008

I wouldn't touch them with a bargepole if I can help it. As far as
C++ey API goes, may be this

http://eigen.tuxfamily.org/index.php?title=API_Showcase

will convince to think twice, if not more.
>
> On Sat, Sep 5, 2009 at 10:26 PM, Rohit Garg<address@hidden> wrote:
>> I think using eigen over gsl (for linear algebra) is a no brainer.
>>
>> a) gsl is dog slow compared to eigen (no vectorization whatsoever).
>> b) gsl has no float option
>> c) eigen offers both column major and row major storage
>> d) eigen *does* expression templates
>> e) eigen will happily map your data and perform operations on it.
>> f) eigen has way cooler (aka C++-ey) api over gsl/lapack
>> g) eigen is adding support for sparse matrices at a rapid pace.
>>
>> For (nearly full, I think) lapack to C++ bindings, FLENS is a great
>> idea too. But I have never used flens.
>>
>> http://eigen.tuxfamily.org/index.php?title=Main_Page
>>
>> I would recommend using eigen/FLENS over gsl anyday for linear algebra
>> purposes. BTW, it also does small vectors/matrices. :)
>>
>> DISCLAIMER: I have contributed and continue to contribute to eigen.
>>
>> On Wed, Sep 2, 2009 at 1:38 AM, Rodney Sparapani<address@hidden> wrote:
>>> John D Lamb wrote:
>>>>
>>>> I’ve written some wrappers for GSL matrices and vectors and might can
>>>> help if someone has a suitable project.
>>>>
>>>> While Rodney is right that there are some issues with creating a
>>>> practical OO interface, C++ is not the same as OO and OO is not the same
>>>> as operator overloading (assuming OO means object orientation).
>>>>
>>>
>>> I was talking about both OO and operator overloading.
>>>
>>>> Another approach to wrapping GSL functions for C++ is to use shared
>>>> pointers, namespaces and exceptions. Typically I might create a class
>>>> gsl::vector that is an extended shared pointer and whose member
>>>> functions look much like the original functions. The main benefit is not
>>>> having to deallocate memory explicitly and only once.
>>>
>>> Well, it seems like there is plenty of interest.  We should all work
>>> together and create an add-on.  We can call it GSL++.  I'm in the
>>> process of working on my PhD which will mean that I'll have an
>>> ample opportunity to use it.  However, I strongly recommend that
>>> the test-bed be integral rather than an after-thought.  For each
>>> feature, there should be a corresponding check.  I don't really
>>> understand dejaGNU/etc. so I can't contribute much to this aspect.
>>>
>>> Rodney
>>>
>>>
>>>
>>> _______________________________________________
>>> Help-gsl mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/help-gsl
>>>
>>
>>
>>
>> --
>> Rohit Garg
>>
>> http://rpg-314.blogspot.com/
>>
>> Senior Undergraduate
>> Department of Physics
>> Indian Institute of Technology
>> Bombay
>>
>>
>> _______________________________________________
>> Help-gsl mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/help-gsl
>>
>
>
>
> --
> HZ
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay