Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 19 Nov 2010 00:52:13 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] CMA-ES optimization algorithm
Message-ID: <20101118235213.GU10411@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <889050.22507.qm@web28607.mail.ukl.yahoo.com>
 <20101118152356.GR10411@dusk.harfang.homelinux.org>
 <4613.54970.qm@web28614.mail.ukl.yahoo.com>
 <20101118170107.GT10411@dusk.harfang.homelinux.org>
 <08ae01cb876c$fb7b4a50$f271def0$@yahoo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08ae01cb876c$fb7b4a50$f271def0$@yahoo.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-DCC-scarlet.be-Metrics: sif 20002; Body=1 Fuz1=1 Fuz2=1

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