On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
<gil...@harfang.homelinux.org> 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.
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
--
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
URL: http://www.lri.fr/~hansen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
