LAPACK Archives

[Lapack] [lapackers] bug in DGEHRD

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/lapack-forum/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.






<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or