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

Reply via email to