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