On Tue, Nov 20, 2012 at 05:08:23AM -0500, Konstantin Berlin wrote: > I am ok with option 2.
Thanks. I'll add new constructors if nobody has objections. Please note that by using "custom" checkers (even those defined in CM), you make some algorithms deviate from their "standard" behaviour. > > 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". Reaching the maximal count is "bad" because it means that the algorithm could not fulfill the (other) input requirements. The "maxEval" parameters was intended as a safe-guard to prevent the algorithm from _unexpectedly_ running too long. If the user knows that it takes a long time to find the solution with the required accuracy, he can increase "maxEval". As I said previously, your request introduces a conflict: It becomes possible that none of the convergence requirements is met. > 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. But that's part of the behaviour inherent to some algorithm. However it will terminate as it wishes (i.e. satisfying its internal convergence criteria). > > That is why if you look at matlab fminunc, it contains about 5 > different flags for termination. That would probably require a new API. Can you give some examples of usage? Concrete proposals are always welcome and would hopefully open a discussion. > This probably goes along with the point in the 873 bug that talks > about internal vs external criteria. Not sure. There, "internal" or "external" (for lack of better words) are both "legitimate". The number of iterations is not (IMHO), because it's sort-of "unstable": If you increase the number of evaluations (or iterations), you can get another solution. I think that this difference in nature is a property that could serve to define an API (as was done with the current one). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
