Thanks to you both for your review. > > 0) maybe incrementIterationCount in the manager should be called > startIteration > OK > > 1) I guess TooManyEvaluations is the only thing left to throw, but > MaxIterationsExceeded or even something new like IllegalIteration > might make sense here (bad name, but once we introduce > StoppingCriteria, something like that will make sense). > As I said, TooManyEvaluations was just temporary. For the time being, I wanted to avoid the burden of defining a new exception with localized messages, until we agreed on the general outline. I would have defined a TooManyIterationsException in the end, but I think I like Gilles solution much better. This would avoid defining a new exception which would not be very instructive in any case. Much better to define a particular exception for the particular type of iterative algorithm. > > 2) It is tempting to go ahead and define the StoppingCondition and > add it as a constructor parameter for the manager. > In fact, that's the purpose of the shouldStop() method. By default, it returns false, but you can override it, which effectively allows you to define a custom stopping criterion, without having to define a general framework for stopping criteria, which previous discussions showed it would be difficult to do... So I would say that we do not need to add a new constructor parameter. What do you think? > > 3) Incrementor is a little crippled not exposing a constructor with > the max - could be we should add that and use it in the manager. > > 4) Similarly Incrementor could expose a hasMore() or somesuch, which > would provide a meaningful default for shouldStop and also provide > the basis for an iterationsExhausted event. > I should first mention that I've tried the present framework with iterative linear solvers, just to check things worked properly. The way I see things is as follows. As Gilles mentioned in a previous thread, a default stopping criterion *should* be embedded into the iterative algorithm. The reason for this is twofold: i. simplify most user's life, and ii. allow for optimized implementation of these stopping criteria. Regarding point ii., computation of the norm of the residual comes as a by-product of the Conjugate Gradient method, while evaluation by a custom stopping criterion would require an extra matrix-vector product *at each iteration*. Having in mind this, I decided that IterationManager.shouldStop() should provide an *additional* stopping criterion, meaning that the iterations are stopped if one of these conditions are fulfilled 1. maximum number of iterations reached ===> throws an exception, already handled by the manager (nothing to do with shouldStop()) 2. the default stopping criterion is fulfilled 3. manager.shouldStop() returns true (which it does not in the default implementation, but that can be overriden). It should be noted that bypassing the default stopping criterion should be fairly easy, by providing "impossible" tolerance requirements. Then only the custom criterion would be checked.
As I said, I've implemented this into my CG, it leads to fairly easily readable code (but certainly improvable, too). So what do you think of this way of thinking of stopping criteria? It seems to me that it is a very general framework, since it does not define any framework at all. It just opens a door to let some external objects inform the Iterative Algorithm that it should stop. Would it be regarded as acceptable design, or very ugly trick? > > 5) It may be extra noise and I know we need to be careful with this, > but a fireIterationStarted source might be useful in some contexts. > If I understand correctly, here is what you would like to have in a typical iterative algorithm {code} // Do initialization work manager.fireInitializationEvent() while(true){ manager.fireIterationStarted() // do some work manager.fireIterationPerformed() } manager.fireTerminationEvent() // do some closing work and return {code} I have no objection to that. However, do we require that *all* these events are fired by *all* iterative algorithms, or only by iterative algorithms where it is thought meaningful/useful? Thanks for your comments so far! Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org