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 17:01:07 GMT
Hello.

> >Did you use the "MATH_2_X" or the "trunk" repository?
> 
> 
> I think "MATH_2_X", but will test with trunk. I think the patch should
> be against trunk?

Yes.
There were some changes introduced in the 3.0 development version.

Namely, please have a look at the "BaseAbstractScalarOptimizer" class
in package "direct". It is meant that all implementations inherit from
that class for consistency; it contains the boiler-plate code for e.g.
counting function evaluations. 
In fact, subclasses only have to implement the "doOptimize()" method and the
algorithm-specific code must call "computeObjectiveValue(point)" in order to
evaluate the objective function at "point".

If you encounter any problem, I'm ready to help in adapting the code.

> 
> [...]
> 
> >None of the CM algorithms do that.
> >No logging is a CM limitation and sometimes a problem (e.g. for debugging).
> 
> Adding the possibility to inject a logger/plotter (for instance as optional 
> constructor
> argument) were only the interface is part of CM would not violate the
> "no external libraries requirement". But it would not make logging/plotting 
> completely
> impossible when using CMA-ES.

The problem is that we would again be re-inventing some wheel which IMHO
doesn't belong to a low-level math library such as CM.
A basic logging interface already exists: It's "slf4j".

Making a logging interface part of the algorithm interface is IMO far worse
than accepting to depend on "slf4j".

> [...]


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