RE: computer-go: Why Ko

[Jean-Pierre Vesinet <jpvesinet@xxxxxxxxxx>]

> I know ko is supposed to be one of the most subtle and 
> important aspects
> of the game, but its a funny rule in that no-one can gain anything by
> breaking it: 
> 
> If you take the rule as `never repeat a previous board state' 
> then if a
> program does do this then wahey! its back to square one. :)

OC, you gain a lot, for example, by being able to retake a ko stone
immediately. This means that all your ko stones are uncapturable. This is
not the same game as go - the ko rule is essential.

Without the ko rule White cannot be captured:
. . . . . .
. . . . . .
. . X X X X
. X X O O O
. X O . O .  (Bottom-right corner)

>  I was just wandering if I should trouble to include a 
> ko-checker in my RL
> based program: hopefully, it should prefer a quick reward to 
> a delayed one
> and learn to follow the ko rule of its own accord.

How can a rule of the game be learned?
About quick rewards, go is typical of a game where delayed rewards are
preferable to quick ones. Only the score at the end of the game matters.

Ko is not well understood by most programs, including some of the best (Wulu
for example). This doesn't prevent it from playing rather well, only it
obviously underestimates the value of ko. I remember playing a game against
the 13x13 demo version of Wulu where it believed a big group of mine was
dead when it was actually alive in ko. It lost the game because of this.

There was a discussion on rec.games.go a few months ago about the "value of
ko". In terms of score, how many points would it bring you if you had an
unlimited supply of virtual ko threats - that's the same as ignoring the ko
rule, but only for one of the players. I wouldn't be surprised if the
average were in the 30 - 100 points range. But computer programs make so
many big mistakes during a game that this may be negligible!

So it may be a good idea to ignore the ko rule as a first approximation. Or
even better ignore the ko rule for one of the player and evaluate the
position. Then do the same for the other player. If there is any difference,
then ko matters and you should be looking for ko threats. If it doesn't then
you have made a faster search by ignoring the possibility of ko. I think
GoTools does something like this. First a search is done without ko, and
using a hashtable, then, if needed, a search is done for ko, with an
increasing number of virtual ko threats (up to five) to see how they change
the outcome.

Any ideas about this sort of simplification to the rules?

Jean-Pierre