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 commonsmath. 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
DormandPrince 8(5,3) solver to a GraggBulirschStoer, 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, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
