commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolaus Hansen" <>
Subject Re: [math] CMA-ES optimization algorithm
Date Mon, 22 Nov 2010 18:28:32 GMT
On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
<> wrote:

> 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...

> 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. 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.
> 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".
>> 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.
>> 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. :-)

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.


> 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:
> For additional commands, e-mail:

Nikolaus Hansen
INRIA, Centre de recherche Saclay -- Ile-de-France
Machine Learning and Optimization group (TAO)
Universite Paris-Sud
LRI (Bat. 490)
91405 ORSAY Cedex, France
Phone: +33-1-691-56495, Fax: +33-1-691-54240

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message