[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Re: Languages and bugs



Chrilly Donninger wrote:
> According my statistics there is a clear relation with the difficulty of the
> concept/problem. The hot-spot in a chess-program is enpassant. It is
> unbelievable how many enpassant-bugs one can make. The Deep-Blue team never
> managed to produce a chip which had no enpassant-bug. Second place is
> castle. In both cases depend the legal moves not only on the current
> position, but also on the game-history. These bugs are not direct
> programming bugs (see example below). One has simply missed some special
> cases.
> I could imagine that Ko is the enpassant equivalent in Go.

Ko is probably the closest analogy in go, but I imagine it can't
really compete with enpassant. I do remember that GNU Go at some time
wouldn't allow a player to capture a ko and then immediately connect
it (in local search the same player is sometimes allowed multiple
consecutive moves).

Another problem with somewhat similar characteristics is filling of
dame. It is not obligatory for a go program to do this, especially not
if it plays with Japanese rules, but for GNU Go the aim is that this
should be done before passing. In principle this is a question of
detecting empty vertices adjacent to vertices controlled by both
players and then playing those. This may sound simple but it is very
easy to
* get the logic wrong and not even find all such vertices
* get the logic wrong and start filling in own territory
* get the logic wrong and start giving away stones in opponent territory
* fill dame and put oneself in atari
* fill a critical dame in a semeai, thereby losing it
* fill dame and lose a liberty which is fatal in some other respect
* detect such troubles (correctly or incorrectly) but failing to find a
  move to forestall the (possibly imagined) problem
* incorrectly detect such troubles and pointlessly playing moves to
  forestall the imagined problem

In fact it's surprisingly easy to fail already on one of the first
three points. As an extra bonus GNU Go for a long time spent an
inordinate amount of tactical reading in the search for dame points,
causing passing at the end of the game to be drastically slower than
the late endgame moves.

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/