commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [math] Monitoring iterative algorithms
Date Fri, 02 Sep 2011 01:38:44 GMT
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,

[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:
For additional commands, e-mail:

View raw message