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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
