Hi, I'm reviving this thread to let you know that I took the liberty to create a new JIRA ticket on this issue (see JIRA MATH-655). A few classes are attached to this ticket for you to review. These classes provide support for managing the iteration count as well as event occuring before, during and after the main iteration loop. These classes do *not* provide yet support for stopping criterion. I am willing to have a go at this, but it seems it will be difficult to get it right (see discussions on MATH-413) [1], and I would like to keep in mind Phil's recommendations > > I think if you are careful, you can likely set this up so that you > can continue to add features to the event framework (or even add the > framework itself) and stopping criteria without breaking backward > compatibility in 3.x releases. > > I would like to see this in 3.0 if you can get something simple > completed that can be enhanced incrementally in 3.x and possibly > refactored in 4.0. >
Do you think the proposed classes could be useful? Do you think the above requirements are fulfilled? If the answers are yes, where should they go? Best regards, Sébastien [1] Whatever is done on stopping criteria, I think that one important point made in MATH-413 is that a default stopping criterion should be hard-coded in the algorithm, for two reasons: i. implementation is usually straightforward (e.g. the residual is already available, and does not need to be recomputed), and ii. end-users might well be very happy with this default stopping criterion. So, the stopping criteria we are talking about here should really be understood as *additional* stopping criteria. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
