On Sun, Sep 6, 2009 at 8:59 PM, Hongzheng Wang <wan...@gmail.com> 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<rpg....@gmail.com> 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<rspar...@mcw.edu> 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 >>> Help-gsl@gnu.org >>> 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 >> Help-gsl@gnu.org >> 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 _______________________________________________ Help-gsl mailing list Help-gsl@gnu.org http://lists.gnu.org/mailman/listinfo/help-gsl