I really don't think that a general progress listener framework implies this
clutter and for long running algorithms is
a very nice thing. CM does not actually have all that many long running
algorithms.
On the other hand, the proposed interface is not a general progress listener
and is not a good idea (IMHO).
On Thu, Nov 18, 2010 at 3:52 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> >
> > 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...
>
