Hello.
> >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
Quite the contrary, I had advocated here that it is light-weight: a library,
such as CM, that would want to offer logging functionality only needs to
depend on "slf4j-api", a JAR that contains only interface declarations.
> and you need some logging library to use it.
This is the heavy-weight part.
And the beauty of "slf4j" is that
1. CM does not depend on that heavy part.
2. A user of CM can choose any library that implement the "slf4j" API.
For people that don't want logging, there is the special "No op" JAR.
>
> 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)
> }
The problem is that you start cluttering the code with interfaces that are
not related to the working of a mathematical algorithm and are meaningful
only in relation to a specific part of the library. Other users would like
to access the internal state of different algorithms; so you could end up
with many such interfaces:
interface ThisPlotter { ... }
interface ThatPlotter { ... }
interface AnotherNiceAlgorithmPlotter { ... }
etc.
Moreover, this would make the list of contructors grow, as well as would
require additional instance variables...
> 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.
I don't mean to imply that it is not useful to check the working of the
algorithm, only that ad-hoc callbacks are not the way to go, IMO.
To avoid the multiplication of interfaces, we would have to design a more
general callback framework; but this is what I meant by "reinventing the
wheel".
> Stochastic optimization
> mechanisms are more powerful, but also a bit more complex as the methods
> already in CM.
I also wish I could investigate bugs with something more flexible than
sprinkling the code with "System.out.println" statements.
But CM is not intended to be a friendly environment for *designing* new
algorithms; that would make too heavy-weight, I think. The algorithms are
"trusted" (because they pass unit tests).
We indeed lack ways to explore the performance of the algorithms on problems
that are not part of the unit tests. I think that having logging statements
which the users can activate at will would be a nice feature. The difference
with your proposed interface is that logging is not intrusive (it is not
part of the API).
> 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?
No, it is because there are strong feelings against depending on external
libraries, and I think that a callback framework is something we should
not try to introduce lightly.
> 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.
Someone wrote a message in this thread about a scripting tool. I did not
look at it, but from the description, this looks promising for uses such as
you mentioned.
> The alternative to provide read access to the statistical data together with
> a flag indicating whether it should
> be generated seems much less elegant.
IMO, what would be elegant is that a logger implementation would interface
with a plotting code that would know what to plot from the log message sent
to it. Again, the message passing framework already exists: "slf4j". You
have the plotting code. Remains the logger implementation, and CM accepting
to depend on "slf4j-api"...
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
