Re:

[Jeffrey Greenberg <jeffg@xxxxxxxxxx>]

Hmm,
This idea of saving state in component-based pattern-speak is known as a Memento
pattern.  It bothers me that your solutions are all inheritance based.  I have
objects that are already of a type and this solution will drive me to multiple
inheritance which has other problems.  A component based solution along the
Memento line frees me of these constraints.  Comments on this?

The alerting described below is known as an 'Observer' and 'Subject' behavior in
which a set of subjects register with the observer as being 'observable'.  On a
change the 'Observer' is used to notify the subjects.   (This too is a component
solution, not an inheritance one.)

How about patterns related to Go?  Maybe then, so code other than wally might be
shared!?!  (At this point, I might actually post some...)

To Tim's interesting point that they designed the 'revertable' data structures so
as not to incur the psychological barrier of not trying algorithms because they
might take too long, I can add that in my experience the boredom of actually
getting the incremental computing right was enough to put me off.  8-)  But in my
case, I'm not so concerned with the compute time as my goal is to derive or learn
knowledge.  As the state-of-the-art for machine learning is rather low, I'm not
bounding myself to the constraints of a game to be played in 1 hours' time.

jeffrey

Tim Klinger wrote:

> >In Indigo, most of objects inherits the Relying_object class (Objet_pose
> >in french). This class has the slot 'intersections' which is the set
> >of intersections on which the objet relies.
> >
> >The slot 'intersections' of a relying object is a reference to the relying
> >object that is very useful in Indigo.
> >
> >For incremental data structure, the Relying_object class has the 'track' slot
> >that is the set of intersections from which the existence of the object
> >depends. When a move is played ouside the track of an object, the object
> >remains and, conversely, when a move is played inside the track then the
> >object
> >is deleted (or saved in a cache).
> >
> >Bruno
>
> We have something sort of similar.  Objects can 'depend' on other objects
> causing them to be alerted when the dependency changes.  They can then
> alert any objects that depend on them, recursively.  Using this as the
> basic structure we built a truth maintenance system (TMS) which monitors
> changes in board occupancy, liberties, and other terms of interest.  Any
> object that needs to can request a constraint that it can 'depend' on.  For
> instance, our pattern matcher works incrementally this way.  When a pattern
> matches, a constraint of the form: color(p1) == c1 and color(p2) == c2 etc.
> is constructed and registered with the TMS.  If later the constraint is
> violated the TMS sends an alert to the pattern match letting it know that
> it is no longer valid.  The match will then send an alert to a database to
> let it know that any assertions about the state made by the match should
> now be revoked.
>
> Tim



--
Jeffrey Greenberg
Mgr. Aegis Adv. Dev.
Acuson Corp.
www.ultrasound.com
www.acuson.com
650-694-5422