Le 21/11/2010 19:12, Nikolaus Hansen a écrit : >> Oh. >> That is very different. >> So why not have either >> a) three getters to get the different matrices >> or >> b) one getter that returns a structure packaging these matrices? >> Why use a callback structure? > > in fact, it can and should serve both purposes: display the result of > finished runs and display the result of long runs that are not finished > yet. Let me add that this functionality is of interest not only for > debugging and algorithm design considerations. It serves also to get > hints on how to (re-)design of the objective function. The latter is to > my experience a typical user case, in particular if the problem at hand > is difficult to solve or not too well understood.
There is something loosely similar to what you need in the ODE packages. This kind of algorithms also need some information to be provided back to users during the algorithm run. For ODE solvers, it is at the end of each integration step. We have set this with a StepHandler interface. If the user wants to get this information, he implements this interface and provide an instance to the ODE solver by calling addStepHandler() before starting the integration. During the integration, the handleStep() method of his instance will be automatically called at each step. This is not intended to be a general facility. It is devoted to the case of ODE and is in fact a very important part of ODE. So there is something existing in commons-math. Perhaps you could design a similar set of features for optimization with a IterationHandler interface ? In the case of ODE, we found a general enough interface that could be used for any type of solver (i.e. if the user switches from a Dormand-Prince 8(5,3) solver to a Gragg-Bulirsch-Stoer, he would not change his step handler implementation). I'm not sure this would be as general with optimizers but it may be worth trying to go this way. Luc > > Niko > >> On Fri, Nov 19, 2010 at 1:55 AM, Dr. Dietmar Wolz >> <drdietmarw...@yahoo.de>wrote: >>> And it was not meant to monitor "progress" but it was intended to be >> called >> > only once >> > to transfer statistical data related to the whole optimization run. >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
