|[eigen] Progress and plans|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
I thought it might be useful to give you a general update so that you can
take it into account when making plans during the meeting. I hope that
you'll be able to report some of your conclusions back to the list.
The MatrixFunctions module is almost ready for release (more details
further down). I plan to continue working on Eigen, but the course I'm
teaching at the moment is proving a lot of work so I have little spare
time. Thus I'm glad I decided not to come to the meeting. The students are
having their Easter break starting 22 March; I hope that will give me a
bit of air. Initially, my plan was to work on precision-oriented testing
and I thought a bit about it (see below), but at the moment I'm not sure
whether I'll have enough time to have something in place in time for 3.0.
An alternative would be for me to improve the tutorial, which has the
advantage that even a little time yields results.
I welcome suggestions on what areas it would be most useful for me to
Status of MatrixFunctions module
The module contains implementations for good algorithms for computing the
matrix exponential and (hyperbolic) sine and cosine, and entire functions
in general. The main function missing is the logarithm.
I think the module is usable at the moment. However, there are some
problems if the matrices have clustered eigenvalues (this is the most
difficult case). One issue is that ComplexSchur often reaches the maximum
number of iterations. I don't know whether that's an inherent weakness in
the algoritm or only in the implementation - it may be as simple as
increasing the maximum number of iterations. There seems to be another
issue in matrix_function_3, which I haven't investigated yet. My guess is
that the test matrices are simple too difficult to evaluate the matrix
functions at the desired precision, which is dummy_precision() for floats
= 1e-5 = 200 * machine epsilon. The test with double seems to go okay and
dummy_precision() for doubles = 1e-12 = 10000 * machine epsilon; any
reason why we're so much stricter with floats?
As far as I am concerned, the API is quite okay. The module provides
template <typename Derived>
ei_matrix_exponential(const MatrixBase<Derived> &M)
The return type is a derived class of ReturnByValue. Issues I'd like to
* is the ei_ prefix necessary, given that the function is in the Eigen
namespace? The wiki has the rule "global functions start with ei_" .
* should it be a member function instead? Is this possible while
maintaining the separation between stable and unstable modules?
* related, what needs to be done to get the module out of unstable/ ?
I thought a bit about it, nothing profound, but perhaps you're interested.
The ToDo list on the wiki seems to indicate three possibilities:
1. We write an BLAS/LAPACK interface with Fortran (or C?) bindings so that
we can run the LAPACK test suite directly.
2. We port the LAPACK test suite to call the Eigen routines in C++.
3. We write our own test suite.
My preference goes to option 2. It's difficult to find good test matrices,
so leveraging LAPACK's work is good. Furthermore, it's a good selling
point to be able to say that we pass the LAPACK test suite. My guess is
that option 1 is more work than 2, especially to make it portable.
Fortran/C bindings may be useful in themselves, but we will be up against
a crowded field.
The LAPACK test suite is described in LAPACK Working Note 41, available
Have a good meeting!