Le 22/11/2010 19:28, Nikolaus Hansen a écrit :
> On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
> <gil...@harfang.homelinux.org> wrote:
>
>> Hello.
Hello,
>>
>>> >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.
>>> > [...]
>>
>> Does the this callback possibly influence the working of the algorithm?
>
> No, besides that you might decide to stop the algorithm based on the data.
> This might also imply that you would like to restart it again...
There may also be some information about behavior of the convergence, so
I would say even if it does not change the state of the algorithm, it
may be interesting for some users.
>
>> If so, it's not only information reported back to the user.
>>
>>> What I had in mind was quite similar, a callback interface and a
>>> function very similar to addStepHandler() in the ODE case.
>>> My "StepHandler" interface was rejected because it was specific to
>>> CMA-ES.
>>
>> Not exactly; my concern is more that this kind of functionality is
>> outside
>> the realm of CM. IMO, CM should contain only mathematical/scientific
>> algorithms.
Yes, you are right.
>> Other functionalities (such as logging/reporting) are general
>> enough that tools already exist to provide them and these tools probably
>> have already gone through the design pitfalls specific to this kind of
>> tasks. If the functionality is really of importance, we should not do
>> something quick and (potentially) dirty just because it would be
>> sufficient
>> to fit a single need, because once it is part of the library
>> interface, it
>> becomes fairly difficult to get rid of it when we discover the
>> shortcomings
>> of the design.
You are also right on this, but I would not call this feature a
"logging" feature. It's closer to reporting which is not the same and it
may be interesting for algorithm users as it provides some mathematical
information. I see it much more like StepHandler which is a clearly in
commons-math scope than slf4j which is general purpose.
Of course, you can use a general purpose framework for this sort of
thing, but here I think we are more talking about monitoring a
mathematical algorithm than monitoring a general purpose java program.
>> We recently had "heated" discussions on whether the localization of
>> exception messages are necessary in CM. One argument has been that
>> it's so
>> easy to do that we don't need to rely on external tools (so that CM will
>> stay dependency-free).
>> As you had indicated yourself, the same argument is valid for your
>> reporting
>> interface.
>> However, going on with this argument, we'll see more and more non-math
>> functionality (little "easy" wheels) incrementally creeping into CM.
>>
>>> By the way, looking at the trunk it seems in ODE the thing was
>>> renamed to "EventHandler".
No, it's a different thing. There are both a StepHandler and an
EventHandler interfaces. They don't serve the same purpose and ore often
used at the same time, each for its own purpose.
>>> The question now is:
>>> Is such an event framework useful in general for optimization or is
>>> it specific for CMA-ES?
>>
>> Reporting is always useful.
>
> I agree. For example to report the best objective function value and the
> best solution over time is quite generic. For CMA-ES, further internal
> state variables are of particular interest (in particular step-sizes and
> eigenvalues of the covariance matrix).
>
>> The way to do it in CM is not obvious given the various, sometimes
>> contradictory, constraints (no dependency, clean and lean code...).
>>
>>> Is there a generic "EventState" for optimization as it is for ODE?
>>
>> No, there isn't.
What about something along these lines (of course all names can be changed):
public interface PointsSetsObserver {
public enum Action {
STOP,
CONTINUE
}
public Action pointsSetChanged(List<double[]> pointsSet);
}
It could be used for all Nelder-Mead, Torczon's multidirectional and
CMA-ES. It is probably not well suited for Levenberg-Marquardt or
conjugate gradients.
>>
>>> Should we proceed with the review of the current implementation
>>> without the event handling in place
>>> or should we defer it until the event discussion Is finished?
>>
>> My choice is: "The algorithm first", together with unit tests.
>> I hope that all agree that it's the most important. :-)
Yes, we can start with a bare implementation and add the bells and
whistles afterwards. In this case, they could also be integrated to the
other optimization algorithms if something general enough is found.
>
> I guess so, but just let me emphasize again: having no reports is quite
> a killer for a general recommendation of the code to users, in
> particular because there are alternatives codes that do reporting.
>From the ODE perspective, I second that. Users have often told me the
StepHandler and EventHandler were really important features that make
the difference.
best regards,
Luc
>
> Cheers,
> Niko
>
>>
>> The discussion on reporting should be resumed in a new thread. [I had
>> started one some time ago (the subject line was "Help in debugging
>> process").]
>>
>>
>> Thanks for your contribution,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> 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
