<div>Hi,<br></div><div><br></div><div>By default using or writing code let the possibility to have bug or instability.</div><div>All library are subject to amelioration and bug fix.</div><div><br></div><div>By looking to the last CCMath release we could see:</div>
<div>"2.2.1<br> 09 Nov 2001 18:15 Minor bugfixes<br>Release Notes: A fix for a rare numerical instability in the singular value decomposition (SVD) code."</div><div><br></div><div>So it's look like recent log from Eigen. All math library are subject to instability and rare bugs.</div>
<div>I see that ccmath by default is not said compatible with windows.</div><div><a href="http://freecode.com/projects/ccmath">http://freecode.com/projects/ccmath</a> => Operating Systems    POSIX Linux</div><div><br></div>
<div>Using code is often a compromise between "portability and reliablility".</div><div><br></div><div>So I think there is not easy solution.</div><div>Lapack (not easy to use on windows for new programmer)</div>
<div>Eigen (portable)</div><div>CCmath (linux only)</div><div>GSL (linux, not easy to use on windows)</div><div><br></div><div>Like you said a possibility is to use the system version of Eigen and provide a default implementation for windows.</div>
<div><br></div><div>I think IPOL code must be easy to compile and so provide a self contained tested solution is the best (in my opinion).</div><div><br></div><div>Regards,</div><div>Pierre</div><div><br></div><div>PS: 
And SVD on very small number often is discarded because a degenerate configuration have been found before by the programmer.
</div><div>And often the code provided for a submission have been tested on large dataset and so critical case could be detected and under control.</div><div><br></div><div>When you look to all the project that use Eigen as main computational library we could consider it as stable.</div>
<div>ROS, Google,  VcgLib, PointCloudLibrary ...</div><div>And personally I never encounter instability.</div><div><br></div><div>It could be a long debate, but it's important that anyone could provide it's point of view.</div>
<div><br></div><br><div class="gmail_quote">2011/11/5 Nicolas Limare <span dir="ltr"><<a href="mailto:nicolas.limare@cmla.ens-cachan.fr">nicolas.limare@cmla.ens-cachan.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
I already wrote about the problems that can happen from embedded<br>
libraries, with the libtiff example[1].<br>
<br>
[1] <a href="http://tools.ipol.im/wiki/author/code/embedding_vs_security/" target="_blank">http://tools.ipol.im/wiki/author/code/embedding_vs_security/</a><br>
<br>
I had a look tonight at the Changelog for Eigen. Since version 3.0,<br>
released March 19, 2011, there has been 3 minor updates. The changelog[2]<br>
mentions the correction of various bugs.<br>
<br>
syntax and memory bugs<br>
* Standard compliance: fix aligned_allocator and remove uses of long long.<br>
* Fix memory leak issue for scalar types throwing exceptions.<br>
<br>
bugs related to some compilers<br>
* Fix compilation on gcc 4.6<br>
* Fix compilation with MSVC 2005<br>
* Fix compilation issues with MinGW<br>
<br>
numerical bugs<br>
* Fix bug in trapezoidal matrix time matrix product.<br>
* Fix asin.<br>
* Fix solve using LDLT for singular matrices if solution exists.<br>
* Fix infinite loop when computing SVD of some matrices with very small numbers<br>
<br>
[2] <a href="http://eigen.tuxfamily.org/index.php?title=ChangeLog" target="_blank">http://eigen.tuxfamily.org/index.php?title=ChangeLog</a><br>
<br>
This means that every software published in IPOL swith all the Eigen<br>
library will have these bugs, forever. When you consider that Eigen<br>
was used by some IPOL software for the SVD, and this SVD was buggy with<br>
a chance of infinite loops, I think this clearly shows why including<br>
the full code of an external library is a bad decision.<br>
<br>
If we accept Eigen in the list of external libraries allowed for IPOL<br>
software (someone will have to explain why we must consider Eigen<br>
portable, widely used and stable), then every IPOL software can<br>
use Eigen ftom the system, and just #include <Eigen>. The version<br>
installed on the system will be updated when new versions are<br>
released, and will correct bugs.<br>
<br>
If we don't accept Eigen in the list of external libraries, and you<br>
still don't want to use lapack, then I think simple stand-alone<br>
implementations like ccmath/svdval[3] for the SVD are less likely to<br>
need updates and corrections for specific compilers.<br>
<br>
[3]<a href="http://dev.ipol.im/git/?p=coco/ccmath.git;a=blob;f=manual/C01-matrix#l708" target="_blank">http://dev.ipol.im/git/?p=coco/ccmath.git;a=blob;f=manual/C01-matrix#l708</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nicolas LIMARE - CMLA - ENS Cachan    <a href="http://www.cmla.ens-cachan.fr/~limare/" target="_blank">http://www.cmla.ens-cachan.fr/~limare/</a><br>
IPOL - image processing on line                          <a href="http://www.ipol.im/" target="_blank">http://www.ipol.im/</a><br>
</font></span><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk61qqYACgkQvviFAPpCP091JgCeO6q9kzD2rO5kJ/cIqkvgQgZ3<br>
5gAAoKrRx2+N4qjsxv4B3VX5L10YbMcu<br>
=+ev9<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@list.ipol.im">discuss@list.ipol.im</a><br>
<a href="http://tools.ipol.im/mailman/listinfo/discuss" target="_blank">http://tools.ipol.im/mailman/listinfo/discuss</a><br></blockquote></div><br>