Le 18/11/2012 10:53, Sébastien Brisard a écrit : > Hi, Hi all,
> > > 2012/11/17 Gilles Sadowski <gil...@harfang.homelinux.org> > >> On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote: >>> I think MATH-902 makes a reasonable request, but I don't think the >>> exception is the right place to communicate last iteration data. >>> When iterative algorithms fail to converge and TooManyEvaluations or >>> other iteration bounds exceptions are thrown, the request in >>> MATH-902 is to make the last iterate available as a field in the >>> exception. My inclination would be to not to do this, but instead >>> to adopt the convention that the class doing the iteration should >>> maintain last iteration state information. >> >> I understand the temptation to provide such a facility but it will make >> the implementation more complicated (additional bookkeeping) than necessary >> for the regular case, by which I mean that inputs were passed that don't >> lead to failure. >> Indeed, correct usage rests on the user, who is responsible for providing >> compatible values for maximum number of evaluations and the convergence >> criteria. >> The current design stems from the consideration that is "maxEval" is >> reached, it means that something has gone wrong: it took more evaluations >> than the _user_ was expecting. >> If this check gets in the way (as suggested by MATH-902), the user can >> always pass "Integer.MAX_VALUE", thereby disabling the safe-guard; but he >> must accept that he might wait a long time... >> >> It would be easier to figure out which approach is correct if we could have >> a concrete use-case.[1] >> >> The same issue also occurs with iterative linear solvers. I have concrete > use-cases, in this instance. Some of the systems I try to invert are quite > large (as in 128 * 128 * 128 * 6 unknowns). If the system is > ill-conditioned and the requirements on the stopping criterion is too > stringent, then the whole inversion will fail because of the maximum number > of iterations being reached. Now, failure is so "brutal" (meaning: nothing > is returned) that you can't even know how close the best estimate of the > solution is to the true solution, so you don't even know how to alter the > parameters of your solvers for failure not to happen again. Since these > iterations take a long time, this is a bit annoying. > > With iterative solvers, there is a work-around, using the event handling > that is provided, which allows access to the *current* estimate of the > solution. > > So I agree with Phil that it would be nice to retrieve the "best" estimate > of the solution, even if crash occurs. But I also agree with Gilles that > this must be done carefully. All the iterative solvers implemented so far > are almost state-less. The only class variables are related to the stopping > criterion. No data relating to the current system being inverted is stored > as a class variable (and is therefore not accessible). Again, event > handlers might be the way to go, we could add an event which is fired prior > to throwing the failure exception. I like a lot the idea of registering user event handlers to be called back by the solver at each iteration. This can be used to only overwrite better solutions as they are found, but it also has many more usages like displaying progress. This is what Nikolaus asked for when we implemented CMAES. I'm not sure about the API though. Either we could pass many parameters (number of iterations, current point and value) or simply a reference to the optimizer, and add custom getters for each optimizers, so the user could retrieve specific information when they know which optimizer type they use and they can cast the refererence to call algorithm-specific getters abnout the current state. We already have something roughly similar to this in the ODE package. We have both step handlers and events handlers, but they have slightly differente meanings to what is desired here. Perhaps we should use a name like IterationHandler to avoid confusion. best regards, Luc > > Best regards, > Sébastien > > > Regards, >> Gilles >> >> [1] There is a similar situation with "CMAESOptimizer": >> https://issues.apache.org/jira/browse/MATH-873 >> It behaves as the reporter of MATH-902 would like all optimizers to, >> but it changes completely the meaning of "maxEval" (instead of a >> safe-guard, it becomes a "normal" termination condition and the user >> must check whether the convergence criteria have been met or not). >> >> --------------------------------------------------------------------- >> 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
