[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096640#comment-13096640
]
Luc Maisonobe commented on MATH-655:
------------------------------------
As a side note, I have compared with design with the needs of the ODE package.
Here are the main differences I see.
In ODE, event detection (i.e. what occurs before firing the event) is almost
the main feature, it is done using the g() function which performs the bridge
between a continuous state and discrete events. I think this could not be
extended to general purpose events, so leaving detection out of the API as you
proposed it is a good idea. We could use this framework and would still need
out own code to adapt to it. Typically, we would keep our g function, and the
ODE solver would use it to fire the event.
In ODE, event detection and handling are grouped in the same object, and
independent of other events. This means that if class cA detects and handles
event eA, class cB which is dedicated to event eB will never be notified for
this. In your design the exact opposite approach is taken: events firing and
handling are decoupled, and classes listening for events will be notified for
all events, not only one. Here again, I think your approach is a good idea, and
it is closer to well known design patterns. We could probably deprecate our
EventHandler interface and replace it by one interface for detection (using the
g function) and another interface for listening.
> General framework for iterative algorithms
> ------------------------------------------
>
> Key: MATH-655
> URL: https://issues.apache.org/jira/browse/MATH-655
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 3.0
> Reporter: Sébastien Brisard
> Priority: Minor
> Labels: algorithm, events
> Attachments: iterative-algorithm.zip
>
>
> Following the thread [Monitoring iterative
> algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
> here is a first attempt at defining a general enough framework for iterative
> algorithms at large. At the moment, the classes provide support for
> * maximum number of iterations
> * events handling
> ** initialization event (prior to entering the main loop),
> ** iteration event (after completion of one iteration),
> ** termination event (after termination of the main loop).
> These classes do not yet provide support for a stopping criterion.
> Some points worth to note
> * For the time being, the classes are part of the o.a.c.m.linear package.
> * For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
> a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
> into CM, then a proper {{TooManyIterationsException}} should be created, from
> which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
