commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-655) General framework for iterative algorithms
Date Sat, 03 Sep 2011 11:44:10 GMT

    [ 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=K4w@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

       

Mime
View raw message