Reliability

From Eigen
Revision as of 15:20, 23 February 2011 by Bjacob (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

"The Fast drives out the Slow even if the Fast is wrong." --- W. Kahan

Any matrix library has to make trade-offs between speed and reliability. Eigen's bias is towards reliability. That may or may not be related to the fact that its founder is a former non-applied mathematician.

Choice of algorithms

As our table of decomposition shows, we have a bias towards pivoting algorithms. Where applicable, we tend to provide both a partial-pivoting algorithm that offers a quite good speed/reliability trade-off, and a full-pivoting algorithm that's entirely uncompromising on reliability. See for example FullPivLU.

Where we haven't had time to implement these different algorithms and had to start with just one, our bias is again toward reliability. For example, our only SVD decomposition is JacobiSVD and we feel comfortable claiming that, thanks to its fully two-sided Jacobi algorithm, it's the most reliable SVD that you'll find in any library; actually, even LAPACK's working note on the subject only uses a one-sided Jacobi algorithm. This isn't to say that we won't implement faster and less reliable SVD algorithms too in the future.

Test coverage

Our main test suite generates more than 500 executables, testing all of Eigen's features across a wide range of numeric types.

We also have specific tests ("failtests") checking that bad user code that should not compile, actually does not compile. And we have imported a copy of Eigen 2's test suite into Eigen 3's, to guarantee that no regression was introduced with this major new version.

Moreover, we provide a full BLAS implementation built on top of Eigen, and we run the standard BLAS test suite against it. We also have a partial LAPACK implementation, passing the corresponding LAPACK tests.

We engage our user base in testing, by documenting our testing process and by getting beta users to run tests on a greater variety of systems than we could ourselves. We collect results on our dashboard.

We offer many build-system options to run tests in non-standard setups, for example switching the default matrix storage order to row-major.