I am ok with option 2. I guess my issue goes to my problem with the general API. The number of iterations is a stopping condition, as well as all the other conditions that are for some reason called convergence conditions. The number of iterations condition is singled out as "bad", hence it throws an exception, while others don't through an exception, and I guess are considered "good".
However, a stopping condition, even if you exclude the number of iterations condition, does not imply convergence, aka that you found an min point. In a convex solver you have to look at the first and second order optimality condition in order to declare "success". A typical stop of the algorithm could be that it has not made enough progress rather than found the min, but with the current framework this is also considered "good", with the user does not have a clue that something went bad unless they take the solution and start checking themselves. That is why if you look at matlab fminunc, it contains about 5 different flags for termination. This probably goes along with the point in the 873 bug that talks about internal vs external criteria. On Nov 19, 2012, at 10:06 PM, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > Hi. > > [Please do not top-post.] > > On Mon, Nov 19, 2012 at 09:17:39PM -0500, Konstantin Berlin wrote: >> 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. > > I rather think that it is a straightforward usage of the current API. > [And it is much cleaner to always get the result as the output of the > "optimize".] > > Why "conflicting"? One is assimilated to a solution (as you requested) and > the other will generate an exception (signalling a failure). > > As already pointed out, the exception is not the best place to store this > information: in CM, exceptions are assumed to signal incompatibilites of the > input to a method and that method's expectations. > >> Also, it seems like some classes, like CMAESOptimizer, also take number >> iterations in their constructor. > > IMO, that's a bug: > https://issues.apache.org/jira/browse/MATH-873 > [See my remark in the other thread that was started to deal with your request > (with subject "Making last iteration data available when iterative algorithms > fail to converge").] > > > Best regards, > Gilles > >> >> On Nov 19, 2012, at 7:36 PM, Gilles Sadowski <gil...@harfang.homelinux.org> >> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
