Re: [eigen] MAXITER in the Eigenvalue module

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/6/1 joel falcou <joel.falcou@xxxxxx>:
> Jitse Niesen wrote:
>>
>> 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.
>
> in NT² we just have solvers throw a NotConverging exception which makes a
> lot of sense IMHO.

Wow, yet another proof that we don't have the same kind of users. Many
projects out there just disable c++ exceptions, so I wouldn't rely on
them for a _feature_ ! Moreover, if they do enable exceptions, this
forces the user to enclose calls to your API in a try { ... } catch,
because nobody would want to crash on numerical issues. I guess that
_you_ can rely on your users to accept all that - scientific users,
etc. That said I can see that the idea of using exceptions for that
has merit, since it is about reporting an error that only the caller
(far away in the calling stack) knows how to react to.

Eventually  (aka later) we could also add a compile-time option (off
by default) to throw exceptions about that, since, for a user who's
prepared to catch them, that can indeed be more convenient than having
to check error codes.

Benoit

>
>
>