On Sun, Nov 18, 2012 at 11:19:14AM +0100, Luc Maisonobe wrote: > 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.
I don't like what currently exists in "CMAESOptimizer" just because it is ad-hoc code. The justification was that, for "scientific purpose", it is necessary to be able to follow the behaviour of the algorithm. I totally agree with the latter statement, but I do not agree that every implementation should do it in its own way. And, more importantly, if we put this justification forward, there is a much straightforward solution: logging. Logging should be available before sinking into littering the useful code with "infrastructure" statements whose only purpose is to give "real-time" information. As it is, we can probably agree that CM is not suitable for analysing an algorithm's behaviour. But, again, is it the purpose? I think not (from my interpretation of stated goals): users call CM as a black box, and can only assume that given some input, it will provide the correct (= expected) output. Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
