On Tue, 1 Jun 2010, Benoit Jacob wrote:
> [Currently, maximum number of iterations is 30. ]
Hardcoding values like 30 is no good practice. No magic value is the
right one. In my experience that tends to grow like the logarithm of
the matrix size. It would be worth doing some experiments to see what
is the "worst case" number f(n) of iterations needed out of 1000
matrices of size n, and try to infer a formula. It can't be worse than
just taking f(n)=30 for all n.
Of course the value should not be hard-coded. On the other hand,
LAPACK's routine DLAHQR (with the same algorithm as we use) gets away
with it, so it does not seem very urgent. I'll put the value in a new
member variable and perhaps add getter and setter methods, as Gael
suggests. The experiments you suggest are very sensible, I doubt I'll
be doing them very soon.
> [ What to do when maximum number of iterations is reached and >
algorithm has not converged? ]
It would be good, then, to have an "info" field telling the outcome of
the iterative algorithm, like in LAPACK. Something the user could
query with a method like info().
That sounds good. An info() method returning an enum with possible
values Success and NoConvergence.
However, what do we do with MatrixBase::eigenvalues() and
MatrixBase::operatorNorm() ? They use eigensolver objects internally.
Would it be okay to document that these methods may return rubbish in
the very rare case the iterations did not converge, or is there a
better solutions? The only alternative I see is to remove these
methods and force users to use the eigensolver themselves.