Re: [Quantlib-dev] long and possibly inifinite observer/observablenotifying loops

[DU V. DE V. F. G. P. <fra...@ca...>]

Hi Luigi,

Sorry for this wrong analysis I thought that once a LazyObject has been =
updated it doesn't propagate any notification until it has been =
recalculated.=20
Don't you think that this should break any circular chain and solve the =
pb of reconvergency ? As for our setting I must confess that we are =
creating many objects and it is not impossible that the dependencies =
between them have some flaws.
Rgds

Fran=E7ois


-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...]=20
Sent: gioved=EC 22 marzo 2007 16.40
To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
Cc: qua...@li...
Subject: Re: [Quantlib-dev] long and possibly inifinite =
observer/observablenotifying loops


Hi Francois,

On Thu, 2007-03-22 at 13:04 +0100, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> I have found that in some cases we can have some huge (possibly
> infinite) observer/observable notifying chains. (ie: one call to the
> notifyObservers method trigger millions of calls to notifyObservers).
> This obviously occurs when we create a circular observer/observable
> chain and no lazyObject is included in.

True. LazyObject doesn't help, either (see below.) But if you have such
a cycle, there's something wrong in the way you built your objects.

>  But it also occurs in the case of a reconvergent chaining ( ie: a set
> of objects are both observing the same object and are all observed by
> another one) which multiply the number of notifying calls.

Yes, but this can hardly trigger millions of calls. A chain like the one
you described triggers N calls where N is the dimension of the set. To
get quadratic behavior or worse, you'd need two or more recombining
chains in sequence. What kind of setup do you have?

> IMHO we should make more objects inherit from LazyObject (even if they
> are not computing anything actually) taking some extra care about what
> we expose in the base classes. Indeed it might happen that some
> LazyObjects might not act as LazyObjects. Indeed these objects
> (PiecewiseYieldCurve for instance) are bypassing the LazyOject
> behavior by call the notifyObservers method directly. (see update()
> method of PiecewiseYieldCurve).=20

LazyObject has nothing to do with it. Laziness causes it to postpone
calculations, but observers have to be notified immediately. If this
were not so, recalculation might never happen. Let's imagine that a lazy
object receives a notification from an observable. If the lazy object
waited to notify its observers until they ask for calculation, the
observers would not know that something is changed; therefore, they
would not ask the lazy object for an updated value, and the lazy object
still wouldn't notify them. In short, the notification would be lost.

Thus, notification cannot be lazy. And in fact, PiecewiseYieldCurve does
not bypass the behavior of LazyObject; the call to notifyObservers() is
inside LazyObject::update() itself. Although a problem might be that
PiecewiseYieldCurve calls the update() methods of both its base classes,
and therefore ends up calling notifyObservers() twice.

Later,
	Luigi



----------------------------------------=20

No, I'm not interested in developing a powerful brain. All I'm after=20
is just a mediocre brain, something like the president of American=20
Telephone and Telegraph Company.=20
-- Alan Turing on the possibilities of a thinking machine, 1943.=20