Tesuji Go Framework / Chain Administration

Sub-page of TesujiGoFramework

Chain Administration

It's maybe borderline whether chain administration belongs to the basic building blocks or in the 'advanced' section. It's here because it's actually a MoveAdministration implementation that's a bit more advanced in that it also keeps chain-information.

A chain is a set of connected stones by one color. As such they are inseparable. If they get captured they get captured all together. That also means the stones in a chain share their liberties. Since a chain is such a basic unit of information and the number of liberties it has of such vital importance, it makes sense to keep this information available to other parts of a Go-playing engine.

There are many ways in which this information can be obtained. But the basic idea is always the same. What the tesuji.games.go.common.ChainAdministration class attempts to do is to compute and update this information incrementally whenever a stone is played. And when a move is taken back. Taking back a move doesn't happen often in normal play, but it happens very often by modules that read ahead.

So what is the information we'd like to make available and how can we do this as efficiently as possible? Here is an attempt to analyze what is theoretically the minimum amount of computationally effort that is necessary to compute this information.

So it makes sense to define a Chain data-structure. What we'd like to store in it is a list of stones that are in the chain and a list of the liberties that the chain has. This is information that is very suitable for incremental computation.

Whenever a move is played, it always affects exactly the chains directly next to that move played. It's a short list of the possible circumstances that can happen when a stone is added.

  • The move is not next to any stones of the same color. In that case a new chain is created with one stone in it. The liberties of that chain are the empty intersections right next to the move. It takes constant time to do this.
  • The move is next to a single chain of the same color. In that case the stone gets simply added to that chain. Since the stone will occupy one of the liberties of the chain it is added to, this liberty needs to be removed from that chain. This removal potentially takes 'n time', where n is the number of liberties the chain currently has. On average this will take n/2 time. After that, the empty intersections next to the move need to be added as liberties to the chain, provided they weren't liberties of that chain already. That takes constant time.
  • The move is next to more than one chain of the same color. This is the most complex and the computationally most expensive case. The solution chosen is to create a new chain with the current move as its only initial stone. Then the stones of each of the neigbouring chains get added as well. This takes n time where n is the total number of stones of all the chains involved together. Next all the liberties of the neighbouring chains need to be added to the new chain. This takes m time where m is the sum of all the liberties in all the neighbouring chains of the same color. Duplicates are discarded and so is the liberty where the current move is. After that, the empty intersections next to the move need to be added as liberties to the chain, provided they weren't liberties of that chain already. That takes constant time.

This is a copy of the living page "Tesuji Go Framework / Chain Administration" at Sensei's Library.
(OC) 2014 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About