A new Jira issue was recently created
https://issues.apache.org/jira/browse/MATH-442
regarding the contribution of a new optimization algorithm CMA-ES.
--------------------------------
Recently I implemented the optimization algorithm CMA-ES based on
org.apache.commons.math.linear and used it for the GTOC5 global trajectory
optimization contest http://gtoc5.math.msu.su/. It implements the
MultivariateRealOptimizer interface and would nicely fit into the
org.apache.commons.math.optimization package. The original author of CMA-ES
(Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the
creation of a CMA-ES contribution for commons.math.
The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a very
powerful algorithm for difficult non-linear non-convex optimization problems in
continuous domain. See http://www.lri.fr/~hansen/cec2005.html for a comparison
chart. If there is interest I will create a patch including the proposed
implementation for evaluation.
--------------------------------
Currently I am preparing a patch containing the new algo - completing Javadoc
and creating únit tests.
The implementation is already "ported" to commons.math, it is mainly dependent
on the linear package.
It follows quite close http://www.lri.fr/~hansen/count-cmaes-m.php?Down=cmaes.m,
including the new active CMA covariance
update mechanism but without the noise handling capabilities.
Some aspects could be discussed before the first implementation proposal is
finished:
1) Should we use package optimization.direct?
In Jira we already started a discussion about the target package - if noone
objects I will put the stuff
in optimization.direct.
2) Additional search parameters / boundaries
The CMAESOptimizer will implement the MultivariateRealOptimizer and will produce
in many cases good results using the
default parameters. But some of the parameters should nevertheless be
modifiable. Should we create an additional interface extending
MultivariateRealOptimizer which covers this aspect?
3) Output/Plotting
Since CMA-ES is stochastic to find out what went wrong usually requires to
evaluate some statistical data
optionally generated during the optimization.
My proposal is to optionally inject implementations of an interface like
public interface CMAESPlotter {
void plot(List<Double> fitnessHistory, List<Double> sigmaHistory,
List<RealMatrix> meanHistory, List<RealMatrix> dHistory, int
lambda);
}
Implementations could produce text output or graphical plots, I have created an
implementation based on the ptolemy-plotting library.
Since a dependency to ptolemy is probably not desirable for commons.math I don't
plan to include it in the contribution.
Should there be a default implementation producing text file output as part of
the contribution?
4) Random number generation
There is already a thread about random number generation in commons.math. Which
method should be used here?
5) IP issues
IP issues should be clarified with the original author of CMA-ES Nikolaus Hansen
who volunteered to support me in my
effort to produce a CMA-ES commons.math contribution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|