On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
> I think MATH-902 makes a reasonable request, but I don't think the
> exception is the right place to communicate last iteration data.
> When iterative algorithms fail to converge and TooManyEvaluations or
> other iteration bounds exceptions are thrown, the request in
> MATH-902 is to make the last iterate available as a field in the
> exception. My inclination would be to not to do this, but instead
> to adopt the convention that the class doing the iteration should
> maintain last iteration state information.
I understand the temptation to provide such a facility but it will make
the implementation more complicated (additional bookkeeping) than necessary
for the regular case, by which I mean that inputs were passed that don't
lead to failure.
Indeed, correct usage rests on the user, who is responsible for providing
compatible values for maximum number of evaluations and the convergence
criteria.
The current design stems from the consideration that is "maxEval" is
reached, it means that something has gone wrong: it took more evaluations
than the _user_ was expecting.
If this check gets in the way (as suggested by MATH-902), the user can
always pass "Integer.MAX_VALUE", thereby disabling the safe-guard; but he
must accept that he might wait a long time...
It would be easier to figure out which approach is correct if we could have
a concrete use-case.[1]
Regards,
Gilles
[1] There is a similar situation with "CMAESOptimizer":
https://issues.apache.org/jira/browse/MATH-873
It behaves as the reporter of MATH-902 would like all optimizers to,
but it changes completely the meaning of "maxEval" (instead of a
safe-guard, it becomes a "normal" termination condition and the user
must check whether the convergence criteria have been met or not).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
