>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 http://www.lri.fr/~hansen/cmaes_inmatlab.html#testing 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
