[no subject]

[computer-go-owner@xxxxxx]

<3.0.1.32.19980821120959.0069adbc@xxxxxxxxxxxxxxxxx>
X-Sender: bouzy@xxxxxxxxxxxxxxxxx
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Fri, 21 Aug 1998 12:09:59 +0200
To: David Fotland <fotland@xxxxxxxxxxxxxxxxx>, David Mechner
    <mechner@xxxxxxxxxxxxxxxxx>, BOISSE_Serge@xxxxxxxxxxxxxxxxx, Computer Go
    Mailing List <computer-go@xxxxxxxxxxxxxxxxx>
From: Bruno Bouzy <bouzy@xxxxxxxxxxxxxxxxx>
Subject: Re: Incremental Data Structures
In-Reply-To: <3.0.5.32.19980817202856.00865c20@xxxxxxxxxxxxxxxxx>
References: <35D886DB.68B577C5@xxxxxxxxxxxxxxxxx>
    <7AA36E067958D111B78700A0C98999B21D1B3C@SAN_JACINTO>
    <35D5AE7F.F58E8BF6@xxxxxxxxxxxxxxxxx> <35D83099.49518A8B@xxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Mime-Autoconverted: from quoted-printable to 8bit by itesec.hsc.fr id
    MAA26102
X-Sequence: 289
Precedence: list

A 20:28 17/08/98 -0700, David Fotland a écrit :
>At 03:39 PM 8/17/98 -0400, David Mechner wrote:
>>Serge Boisse STNA 7P (33) 562 14 5731 wrote:
>>> David Mechner wrote:
>>> >
>>> > Incremental update done by storing changes adds substantial complexity
>>> > to the program, and requires a great deal of effort to design and
>>> > implement. It has the advantage that, if done well, is nearly
>>> > transparent and puts no pressure on you to steer clear of complex or
>>> > expensive algorithms, allowing you to concentrate on generating the
>>> > information that you think best allows you to solve problems in go.
>>> 
>>> Wrong. it is not transparent at all if the structure is complex : 
>>> [objects' addresses change as a result of reading and/or backtracking]
>>
>>We also made this mistake when we first implemented the system. What we
>>do now to avoid this problem is copy the value of the saved version back
>>to the original location in memory when we revert so all preexisting
>>references to objects remain valid. It's quite transparent.
>
>I've also run into this problem.  After some reading I might revert to the
>same position, but the group numbers are different.  If I had an old group
>number and I use it, I get stale data.  I solve this by using some
>canonical property of each data structure to identify it.  For groups, it
>is the first stone played in the group for example.  I can get the group 
>number from the location of any stone in the group, so I can find the new
>group number.
>
>David
>
>>
>>Tim and I will post the source code for our revertable object system
>>shortly.
>>
>>-David
>>
>>-- 
>>David A. Mechner            Center for Neural Science
>>mechner@xxxxxxxxxxxxxxxxx         4 Washington Place, New York, NY 10003
>>212.998.3580                http://cns.nyu.edu/~mechner/
>>
>>
>
>

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