Hi Marco,
There was a problem in LAPACK DLAHQR indeed. We just fixed it in our SVN
repository.
See LAPACK errata for more information:
http://www.netlib.org/lapack/Errata/index2.html#_strong_span_class_green_bug125_span_strong_xlahqr_v3_5_does_not_converge_on_some_matrices_while_xlahqr_v2_converges
It is not clear how much this will help in your case. I sent your email to
Meiyue Shao and he provides us with some additional insight about your matrix
and your eigenvalue problem. Below is the email of Meiyue. Meiyue: thanks a lot!
Meiyue wrote:
I played with this matrix using matlab (2014b), octave (3.8.0), and
lapack (3.5.0). Below is my concern.
The matrix is upper Hessenberg, graded, and almost rank one.
The two largest singular values are 2.4e13 and 5.0e2.
Although the stopping criteria in DLAHQR attempt to take care of graded
matrices,
in general we cannot expect reasonable relative accuracy on tiny
eigenvalues.
For the "problematic" eigenvalue, the user reported that it varies from
0.77e3 to 0.13e2.
(This is within a factor of two, rather than a factor of ten.)
Both are below eps*norm(A,2) = 5.3e3.
So the absolute error is fine but the eigenvalue is not reliable.
The user states that all but the largest (in magnitude) eigenvalues are
real and positive.
However, lapack, eig(), eig( ,'nobalance') all produce several pairs of
complex eigenvalues.
(The user only prints the real parts.)
This already means that the computed tiny eigenvalues are not meaningful.
As this problem has hidden theoretical properties, perhaps the user
should consider using/developing
a tailored solver instead of general purpose solvers provided by
ARPACK/LAPACK if he cares about
the accuracy of tiny eigenvalues below machine epsilon.
Best wishes,
Julien.
On 2/11/15, 4:15 AM, "Marco Caliari"
<marco.caliari@Domain.Removed<mailto:marco.caliari@Domain.Removed>> wrote:
Dear maintainers,
I'm experiencing the so called "dlahqr convergence problem" in ARPACK. For
a particular example (matrix.txt enclosed) ARPACK converges to the right
eigenvalues with dlahqr.f <= 3.0 and not with 3.5.0. I tried to isolate
the problem. If you run the test you see that, a part from a very large
negative eigenvalue, all the remaining but one are positive. They all
should be positive (the original problem has positive eigenvalues). With
dlahqr 3.0 the negative one has magnitude 1e3, whereas with dlahqr 3.5 it
has size 1e2 and this is enough to confuse ARPACK. I tried to compute the
eigenvalues by Matlab (using LAPACK 3.4.1) and Octave (usign 3.5.0) and
the largest negative has magnitude 1e3 (this is also strange, how do they
compute eigenvalues?).
I hope that this specific example can help to eventually find and fix a
problem in 3.5.0.
Best regards,
Marco Caliari
 next part 
An HTML attachment was scrubbed...
URL:
<http://lists.eecs.utk.edu/mailman/private/lapack/attachments/20150327/4789ffe2/attachment.html>
