Re: [math] Monitoring iterative algorithms

[Sébastien Brisard <se...@m4x.org>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Monitoring iterative algorithms

[Sébastien Brisard <se...@m4x.org>]

I forgot a very important question: would this classes be applicable
to ODEs (see Luc's explanations below). If not, I can probably forget
about them, since, I think this package makes the most extensive use
of events at the moment in CM...
Sébastien
>
> So here are the needs for ODE:
>  - callbacks for regular steps when they complete, without
>   any feedback with the algorithm. This is now implemented using
>   StepHandler and FixedStepHandler and the handlerStep method is void,
>   so from the algorithm point of view this monitoring is almost no-op.
>  - callbacks for discrete events, which may provide feedback to the
>   algorithm. This is now implemented using EventHandler and requires
>   a function to define the event (the g function, events occurring at
>   sign changes) and a function to be triggered when the events occurs
>   (the eventOccurred function, which provides the current state and
>   which return value is used by the algorithm to know what to do next,
>   i.e. continue/stop/reset state/reset derivatives.
>
> These needs are really, really important and in fact are one of the main
> feature in Commons Math ODE (and prior to that from Mantissa) that was often
> praised by users.
>
> Do you think we should design something now for 3.0 or should it wait 4.0 ?
> I would love to have such a new feature soon, but fear it could delay 3.0
> too much.
>
> Luc
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org