commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] CMA-ES optimization algorithm
Date Thu, 18 Nov 2010 15:23:56 GMT
Hello.

> 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.
> 
> [...]
> 
> The implementation is already "ported" to commons.math, it is mainly dependent 
> on the linear package.

Did you use the "MATH_2_X" or the "trunk" repository?

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

That seems fine.

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

No.
All the parameters must be passed as arguments to the constructors.

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

None of the CM algorithms do that.
No logging is a CM limitation and sometimes a problem (e.g. for debugging).
Some time ago, we started a discussion about logging. But it again stumbled
upon the "no external libraries requirement". [The "slf4j", a logger
interface, is all we would need to enable users to produce text files,
without imposing ad-hoc I/O code.]

> 4) Random number generation
> 
> There is already a thread about random number generation in commons.math. Which 
> method should be used here?

The CM "RandomGenerator" should be passed as an argument to the constructor.

> [...]


Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message