There is a permutation that makes this matrix 2x2 block triangular, and the
balance routine seems to be trying to scale down the off diagonal block by
roughly machine precision, solve the eigenproblem, and scale back.
One could imagine a balancing routine that found the strongly connected
components
of the matrix, with the rest of the algorithm permuting them to create
the explicit block
triangular form, and solving the diagonal blocks independently, etc, but
this is a big
change. If we had a lot of call for solving such "sparse" eigenproblems,
it would be
worth it. In the short run, I would use the expert driver and turn off
balancing.
Jim
James Demmel wrote:
The balancing is choosing to scale some rows/columns by factors like
1e18,
which rather amplifies tiny rounding errors in the (presumably correctly)
computed eigenvectors of the balanced matrix, when balancing is undone
at the end.
The expert driver interface dgeevx would let the user disable
balancing, until
we figure out whether this is a bug or a feature, I'm not sure which.
Jim
Julien Langou wrote:
We have a bug report at:
http://icl.cs.utk.edu/lapackforum/viewtopic.php?f=2&t=1818
It comes from Numpy guys.
The matrix is very pretty to look at with a lots of zero and a lots
of structure but DGEHRD does not seem to like, not one little bit.
See post.
Note that while
[V,D]=eig(A);
does not work,
[Q,H]=hess(A);
[V,D]=eig(H);
V = Q*V;
works ...
Ideas?
Best wishes,
Julien.
