[IPOL discuss] the problem with Eigen (and other embedded libraries)

[Nicolas Limare]

Hi,

> When you look to all the project that use Eigen as main computational
> library we could consider it as stable.
> ROS, Google,  VcgLib, PointCloudLibrary ...
> And personally I never encounter instability.

I mean stability of the API. Eigen 2.0 was released in 2009 and Eigen
3.0 was released this year. Do the developers commit to maintain Eigen
2.0 for a long time, or will they only maintain the Eigen 3.0 branch?
How long will the 3.0 branch be maintained? Should we expect an Eigen
4.0 branch in 2013?
There is a page about "Porting from Eigen2 to Eigen3" in the doc, it
seems that the migration is recommended.
-> http://eigen.tuxfamily.org/dox/Eigen2ToEigen3.html

By contrast, I think the BLAS API has not changed since its release 30
years ago, LAPACK 3.0 was released in 2000 and is still in
development. fftw 3.0 was released in 2003, fftw 2.0 was released in
1998 and this branch is still maintained. libpng 1.2 was released in
2001 and is still maintained, in parallel with the recent 1.4 and 1.5
branches.

For external libraries, we need this stability, the possibility to use
them for a long time (PhD+postdoc=5years, SIFT was published 12 years
ago) with new code corrections and bug fixes. Active,
live code in constant development (ROS, Google,  VcgLib,
PointCloudLibrary) doesn't need this stability because the code is
contimuously updated, improved and adapted to changes in external
ibrary. Code archived in IPOL is somehow dead, frozen, and needs a
stable (but not dead) software world around.

> It could be a long debate, but it's important that anyone could provide
> it's point of view.

Yes, and I did not mention (neither recommended nor forbidden) the
inclusion of external libraries in IPOL software in the guidelines
draft.


Minor points now:

> "2.2.1 09 Nov 2001 18:15 Minor bugfixes
> Release Notes: A fix for a rare numerical instability in the singular value
> decomposition (SVD) code."

Oops, I didn't see it. Obviously, there can be (and there ARE) bugs in
every software. My mail was an advocacy of the "external library"
principle, not a case against Eigen.

> I see that ccmath by default is not said compatible with windows.
> http://freecode.com/projects/ccmath => Operating Systems    POSIX Linux

Looking at the code, the only system headers included are math.h,
stdio.h and stdlib.h, so there are probably not much portability
problems. But I have never used or explored ccmath, It was just an
example. And ccmath has other big problems, including no development
for 10 years and no internal comments and documentation.

> Lapack (not easy to use on windows for new programmer)

I found this guide for lapack on windows.
-> http://icl.cs.utk.edu/lapack-for-windows/
And Scilab is distributed with lapack and the Atlas implementation of
blas, I did a quick archive and put it online, if someone wants to
test if these libraries are usable (I did not).
-> http://dev.ipol.im/~nil/tmp/atlas.zip

> GSL (linux, not easy to use on windows)

A DLL is distributed by gnuwin32 but I agree GSL is primarily
developed and tested on UNIX sytems.
->  http://gnuwin32.sourceforge.net/packages/gsl.htm

PS: And how does Eigen compare with other linear algebra libraries,
like Blitz++ and Armadillo?

-- 
Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20111108/57fb1800/attachment.pgp>