Hello. > >There is something loosely similar to what you need in the ODE packages. > >This kind of algorithms also need some information to be provided back to > >users during the algorithm run. For ODE solvers, it is at the end of each > >integration step. > > [...]
Does the this callback possibly influence the working of the algorithm? If so, it's not only information reported back to the user. > What I had in mind was quite similar, a callback interface and a function > very similar to addStepHandler() in the ODE case. > My "StepHandler" interface was rejected because it was specific to CMA-ES. Not exactly; my concern is more that this kind of functionality is outside the realm of CM. IMO, CM should contain only mathematical/scientific algorithms. Other functionalities (such as logging/reporting) are general enough that tools already exist to provide them and these tools probably have already gone through the design pitfalls specific to this kind of tasks. If the functionality is really of importance, we should not do something quick and (potentially) dirty just because it would be sufficient to fit a single need, because once it is part of the library interface, it becomes fairly difficult to get rid of it when we discover the shortcomings of the design. We recently had "heated" discussions on whether the localization of exception messages are necessary in CM. One argument has been that it's so easy to do that we don't need to rely on external tools (so that CM will stay dependency-free). As you had indicated yourself, the same argument is valid for your reporting interface. However, going on with this argument, we'll see more and more non-math functionality (little "easy" wheels) incrementally creeping into CM. > By the way, looking at the trunk it seems in ODE the thing was renamed to > "EventHandler". > The question now is: > Is such an event framework useful in general for optimization or is it > specific for CMA-ES? Reporting is always useful. The way to do it in CM is not obvious given the various, sometimes contradictory, constraints (no dependency, clean and lean code...). > Is there a generic "EventState" for optimization as it is for ODE? No, there isn't. > Should we proceed with the review of the current implementation without the > event handling in place > or should we defer it until the event discussion Is finished? My choice is: "The algorithm first", together with unit tests. I hope that all agree that it's the most important. :-) The discussion on reporting should be resumed in a new thread. [I had started one some time ago (the subject line was "Help in debugging process").] Thanks for your contribution, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
