commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Dietmar Wolz" <>
Subject AW: [math] CMA-ES optimization algorithm
Date Thu, 18 Nov 2010 22:07:24 GMT

>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".

slf4j and the interface I had in mind are completely different things. slf4j
is a generic logging interface meant for textual output. 
It is quite heavy-weight and you need some logging library to use it. 

I had a very simple one-method interface in mind, namely 

public interface CMAESPlotter {
	void plot(List<Double> fitnessHistory, List<Double> sigmaHistory, 
			List<RealMatrix> meanHistory, List<RealMatrix>
dHistory, int lambda)

which provides a kind of call back enabling  the user to receive statistical
data if he wants to analyze the optimization run.
I don't think this means reinventing any wheel.
Please check to see
why this can be useful. Stochastic optimization
mechanisms are more powerful, but also a bit more complex as the methods
already in CM. 

This small interface would be the only  thing which would become part of CM,
any implementation we could leave for the user.
And its use is optional. Do you think, any kind of callback interface
doesn't fit into CM? 
Is it because this design pattern is not yet used already in CM?

CM is open source, so anyone can take the source and add the generation of
statistical data himself if he needs to, 
so of course we can leave it out. But this way he would have to fork the
source and has to merge it later for every version change. 

The alternative to provide read access to the statistical data together with
a flag indicating whether it should
be generated seems much less elegant. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message