>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).
> The problem is that you start cluttering the code with interfaces that > are not related to the working of a mathematical algorithm and are There is a relation "to the working of a mathematical algorithm" but I agree to your point that we should avoid to add too many specific interfaces. All original implementations of CMA-ES support some kind of reporting and in the discussions with the author of CMA-ES Nikolaus Hansen he shared his thoughts about the specific importance of reporting for CMA-ES. So I will drop the "reporting" stuff for now and we can separately discuss whether a general progress listener interface would be acceptable for CM. The proposed interface was specific because its purpose was not to transfer text but specific data (a list of matrices). And it was not meant to monitor "progress" but it was intended to be called only once to transfer statistical data related to the whole optimization run. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
