> > > [...] > >>> I like a lot the idea of registering user event handlers to be called > >>> back by the solver at each iteration. This can be used to only overwrite > >>> better solutions as they are found, but it also has many more usages > >>> like displaying progress. This is what Nikolaus asked for when we > >>> implemented CMAES. I'm not sure about the API though. Either we could > >>> pass many parameters (number of iterations, current point and value) or > >>> simply a reference to the optimizer, and add custom getters for each > >>> optimizers, so the user could retrieve specific information when they > >>> know which optimizer type they use and they can cast the refererence to > >>> call algorithm-specific getters abnout the current state. > >>> > > The first solution is the one used in IterativeSolverEvent, which extends > > IterationEvent. I don't like the second option (using custom getters for > > each optimizers). As I said, iterative linear solvers do *not* hold > > information relating to the system currently being solved. It seems that > > things are a bit different in optimizers, but if we assume that all > > interesting information can be retrieved from the object which actually > > performs the iterations, I think we lose flexibility. > > > > At the moment, for iterative linear solvers, saving the last iterate can > > only be done in an event handler. For example, in the corresponding > > IterationListener, you could use e.getSolution() each time > > iterationPerformed(e) is called. This is potentially costly, though, since > > this returns a copy of the (potentially large) vector x. I think that we > > could add a method to IterationListener, e.g. aboutToFail(e) (for lack of a > > better name). Then a copy of the current solution would be taken only here. > > What do you think? I don't know how applicable to optimizers that would be, > > but it would be fairly straightforward for iterative linear solvers. > > > > > >>> We already have something roughly similar to this in the ODE package. We > >>> have both step handlers and events handlers, but they have slightly > >>> differente meanings to what is desired here. Perhaps we should use a > >>> name like IterationHandler to avoid confusion. > >> I don't like what currently exists in "CMAESOptimizer" just because it is > >> ad-hoc code. The justification was that, for "scientific purpose", it is > >> necessary to be able to follow the behaviour of the algorithm. I totally > >> agree with the latter statement, but I do not agree that every > >> implementation should do it in its own way. > >> And, more importantly, if we put this justification forward, there is a > >> much > >> straightforward solution: logging. Logging should be available before > >> sinking into littering the useful code with "infrastructure" statements > >> whose only purpose is to give "real-time" information. > >> As it is, we can probably agree that CM is not suitable for analysing an > >> algorithm's behaviour. But, again, is it the purpose? I think not (from my > >> interpretation of stated goals): users call CM as a black box, and can only > >> assume that given some input, it will provide the correct (= expected) > >> output. > >> > >> Yes and no. If each iteration of the algorithm is very long, then the > > ability of monitoring the iterations is very useful -- not only from an > > academic point of view, even if I think this is also important, as there is > > no equivalent to CM with these academic facilities you do not seem to like. > > So I would say: the main purpose of CM is not the analysis of an algo. > > However, if that's not too much of a hassle, opening the algos is a plus > > which we should not reject. I think event handlers offer this flexibility. > > > > You mentioned logging. I was not aware of logging in CM, or even on any > > consensus about logging at all. I'm sorry if this is a silly question, but > > what exactly do you have in mind? > > One way to look at this is that logging is what a client app can > choose to do when it gets an event that it wants to log from > [math]. I agree that we should try to do two things to make this > easier for users of [math]: > > 0) expose properties that can be interrogated at run time that users > may wish to observe and log or otherwise persist > 1) design appropriate event listener support into the library > > The current discussion was started by a user request for an instance > of problem 0). We have done some experimenting with 1). I think it > is better to continue that than to add logging (and dependency on > logback or somesuch) to the code. If we give users access to the > properties and events they need, they can do their own logging.
I do not hold the same view of the purpose of logging (or maybe I missed a point here). IMO, the primary goal of logging is to trace the behaviour of a code in order to ensure that an algorithm behaves as expected. I admit that it is neither necessary nor sufficient to prove correctness: it is just a simple tool that usually allows to figure out what is going wrong. [In debugging CM, I guess that we all resorted to the poor man's logging: sprinkling the code with temporary "println" statements...] In logging, the _developer_ decides what information to provide, and the _user_ decides how much of the available information he wants to see (based on the log level). This is not in contradiction with having a more sophisticated setup, but I'd say: simple things first. There would be only one, quite stable and lightweight, dependency: "slf4j-api". Users would just need to choose an actual logging system that implements that API (or put an "no-op" logger JAR in their classpath to disable logging completely). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
