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
