commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <>
Subject Re: [math] 902 Optimizers should return best discovered value in case of TooManyEvaluationsException
Date Tue, 20 Nov 2012 02:17:39 GMT
That would solve the problem. Seems a bit messy though, since you now have two conflicting
stopping conditions, one you provide in the checker implementation, the other in the function
call. I am not clear why if you are throwing an exception you don't provide more information
inside it, so the user can adjust their logic based on it.

Also, it seems like some classes, like CMAESOptimizer, also take number iterations in their

On Nov 19, 2012, at 7:36 PM, Gilles Sadowski <> wrote:

> Hello.
> On Mon, Nov 19, 2012 at 04:47:08PM -0500, Bruce A Johnson wrote:
>> On Nov 17, 2012, at 6:57 PM, Konstantin Berlin wrote:
>>> There are numerous examples when the optimization might not have
>>> converged to the stopping condition, but the minimum discovered point
>>> is better than the starting point that was initially provided. The
>>> user should have the ability to at least decide if it is good enough,
>>> or use it as a starting point into a different optimization run. This
>>> is the behavior that most optimizers have, including MATLAB.
>>> This functionality important when you have a time constraint, where any improvement
in result is better than no information at all. There are also non-convex regions of a function
where the convergence rate is very slow, and you might want to stop.
>>> A simple modification for now is to just let
>>> org.apache.commons.math3.exception.TooManyEvaluationsException contain
>>> within it the best found solution so far.
>> I agree that there are many situations where one is constrained by the amount of
resources one can throw at a problem and the user would like the best solution given those
resources (here, the maximum number of iterations) so I fully support a solution that lets
us get the best solution that has been achieved.  I wonder if it is possible, instead of using
the exception, to specify a convergence checker that checks not only the tolerances, but could
instead return success if the maximum number of iterations has been exceeded.  I realize this
will look inappropriate to some, but using the convergence checker in this way would be entirely
up to the person calling it.  If you can get back the number of iterations used, then presumably
if that is equal to the max  you'll know it hasn't really converged. 
> Your proposal is brilliant: problem solved (IMHO)!
> The convergence checkers are there to allow users to define their notion
> of convergence; and the API provides the current iteration count.
> We could add this feature in CM's "Simple...Checker" implementations by
> adding one constructor (and an if-block in the "converged" method) without
> touching the optimizers.
> The user who passes such a checker will indeed be aware of the implication:
> the algorithm might quietly terminate before reaching the optimal solution.
> Shall I
> 1. resolve the issue as "Not a Problem" (the user should implement his own
>   custom checker) or
> 2. add the constructors in the checkers defined within CM and resolve as
>   "Fixed"?
> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message