[Computer-go] Oh no, dynamic Komi again

Don Dailey dailey.don at gmail.com
Thu Jul 14 08:52:26 PDT 2011

On Thu, Jul 14, 2011 at 8:07 AM, Stefan Kaitschick <
Stefan.Kaitschick at hamburg.de> wrote:

> Am 12.07.2011 11:54, schrieb Petr Baudis:
>    Hi!
>> On Tue, Jun 21, 2011 at 02:13:50PM +0200, Olivier Teytaud wrote:
>>> I have posted too quickly - after all I have something which works both
>>> for
>>> black and white and for various board sizes, using
>>> the "rule 42" spirit. Good news :-)
>>   Glad you got it to work! I updated the preprint on my homepage, now it
>> also contains a graph for handicap games when taking white and shows
>> great effectivity of value-based situational dynamic komi. :-)
>>   Have you gotten some significant improvements from applying this in
>> even games as well? I managed to get only small performance boost, even
>> though my feeling is the whole search process behaves quite differently.
>>   Also, are you using a ratchet-like mechanism like I described in my
>> paper? Exactly why it works the way I found it does is still somewhat
>> a mystery for me...
>>  Just a hand waving explanation for the ratchet: you simply cannot afford
> to cede ground to black when giving a handicap.

In theory you HAVE to cede ground as you have a lost game.    Even though I
do not play much go and I'm not strong, I know that you have to give up
ground in some places to gain ground in others and that is what separates
the men from the boys.

So I can easily imagine that the best way to win when accepting a handicap
is not to try to take the whole board but to calculate what your chances are
and carve out no more than you absolutely need (not get greedy.)     Of
course you have to opportunistic but the algorithm will automatically
respond opportunistically if that improves your chances of winning.     A
lot of times you have to win a big group to win at all so it's not like the
program is trying to win by exact half a point,  it's just trying to win and
that may require it to win by 40 stones in some positions.      I think
people have this idea that the program is "trying" to throw away points but
it's not like that at all and that may even be why people are so messed up
over the concept,  they don't understand what is really happening.

Having said that, I think that in handicap games there has to be a different
strategy.   A thought experiment proves this:

Imagine a program that is virtually perfect,  the playouts are perfect and
the game is played by the program to perfection.    If the game is winnable,
 the program will always win.   If the game is not winnable, such as in a
handicap game,  every move will be futile.    How to convert such a program
into one that can win handicap games?

The most naive solution is to maximize points and as the opponent makes
mistakes the program's odds of winning continues to go up, as does his final
points on the board.      But using this strategy the program may not play
in a way that gives the opponent a problem.    For example if the opponent
give the computer a small group the computer might very well conclude it's
the best it can do because it's model of the opponent is that he will play
perfectly too.   So it will go for the small chain instead of
playing provocatively elsewhere.      The very solution that is generally
proposed  to deal with this is probably self-defeating.

A similar situation could exist in chess - if computers get almost perfect
they may conclude the game is a draw and immediately simplify,  giving
humans the occasionally draw when they would be much more likely to win by
playing provocatively.


> Even though the playouts do not model a weak response by black, a winrate
> of 42% implicitly does assume a weaker opponent.
> When the winrate starts dropping at the current komi level, that probably
> means that the weaker player is going head to head instead of retreating.
> It that situation white must conquer or perish.
> Stefan
> ______________________________**_________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20110714/2a1d4459/attachment.html>

More information about the Computer-go mailing list