commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] Monitoring iterative algorithms
Date Tue, 09 Aug 2011 16:41:46 GMT
On Tue, Aug 09, 2011 at 05:46:47PM +0200, Luc Maisonobe wrote:
> Le 09/08/2011 09:28, Phil Steitz a écrit :
> >On 8/8/11 10:46 PM, Sébastien Brisard wrote:
> >>2011/8/8 Phil Steitz<phil.steitz@gmail.com>:
> >>>+1 to the idea of using the Observer pattern; but -0 for
> >>>Observable.  I would favor defining Events and Listeners because a)
> >>>Observable is concrete, so effectively forces you to create an
> >>>Observable delegate
> >>>
> >>I'm not sure I understand. Components in java.awt also need to
> >>implement quite a few methods like addListener, fireEvent, and so on.
> >>Maybe we could write a DefaultObservable, which would implement most
> >>of the methods required by Observable, and could be inherited by some
> >>(probably not all, unfortunately) of the already implemented iterative
> >>algorithms ?
> >
> >I was suggesting that we dispense with having anything inherit from
> >Observable and just define events and listeners, similarly to what
> >you find in the awt components, but also elsewhere like javax.sql or
> >javax.servlet (and I am sure lots of other places too).  Observable
> >just gives you hasChanged and a primitive, non-type-safe
> >notifyListeners.  To do proper event propagation you need to define
> >custom events anyway and register listeners, so unless all you need
> >to raise are "some state has changed" events (like what a GUI
> >presentation layer needs from the model in MVC), you are better off
> >implementing a proper event framework.  This does not have to be
> >heavyweight.  Just define
> >
> >0) Event class(es) extending j.u.EventObject
> >1) a listener interface extending j.u.EventListener
> >2) implement addXxxListener, removeXxxListener and
> >fireInterstingEvent1...n in the class that you want to be observable
> >(i.e. source events)
> >
> >Items 0) and 1) and most of 2) are going to be necessary anyway if
> >you want to propagate typesafe events.  All that you really save by
> >bringing in Observable is maintenance of the listener collection,
> >which is trivial.
> >
> ><snip/>
> >
> >>Browsing through the JavaDoc, I realized that o.a.c.m.ode has some
> >>event handling facilities. Is the implementer still around?
> >
> >That would be Luc.
> 
> I'm here.
> Sorry for the delay, I am on holidays for three weeks and working in
> my house.
> 
> When I read the first mail in this thread a few minutes ago, I
> thought: this is close to what we have in ODE. Then I remembered a
> discussion with Dietmar and Nikolaus when we met at an optimization
> workshop in Toulouse: they also raised the need for some
> monitoring/logging facility in optimization algorithms. Gilles also
> raise this problem in this thread.
> 
> So I would now say: we do have both an event framework *and* a step
> handler framework in ODE, but they are both tailored for ODE.
> If we can think of a more general framework, I would say this
> framework should be used for all our iterative algorithms and the
> ODE framework should be changed to use it too.
> 
> 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.

It's not only the time to think, implement and test, but also the time to
experiment. Only the latter will be able to tell if the design is good.
And this must take time so that all the potential pitfalls can be
encountered...

Also, for what it's worth, I'd prefer everyone to focus on the open issues
and advance towards 3.0. It's seemed that the thread which you started about
a release plan was rather short-lived. Most unfortunately.


Regards,
Gilles

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


Mime
View raw message