On 19 November 2012 21:47, Bruce A Johnson <johns...@umbc.edu> 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. >
Or it just happened to converge at the same time as reaching max iter count ... I don't think it's possible to distinguish those two cases without further information. > > Bruce > > > > > >> --------------------------------------------------------------------- >> 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
