Hi René,
Yes, if a move is self-atari, then it does not actually "save" a string. I give
such a wording from the view of its intention, but maybe we can name it better.
By the way, it's important to give a probability to such "self-atari
extension", because in some situations it is good. For example, for killing a
group sometimes it's necessary to extend to make a nakade shape, even if it is
self-atari.
As for Feature 7, the other liberty does not have this feature, because it
cannot kill the string. What we mean "kill" is that after the atari-killer is
played, this string has no way (whether by capturing or extention) to prevent
itself from being captured. In my experiments, I discovered that it is good to
make the condition strict.
Aja
----- Original Message -----
From: René van de Veerdonk
To: Aja ; [email protected]
Sent: Sunday, October 10, 2010 12:16 PM
Subject: Re: [Computer-go] Monte-Carlo Simulation Balancing in Practice
Aja,
Thank you for your answer. Could you clarify what you mean by "killing" and
"saving" in your paper? For instance, an extension that results in the extended
string still in atari does not really "save" the string, as it can still be
captured on the next oponent move. I understand that this is the difference
between feature 2 and 3, but the wording in the paper identifies both
situations with "saving" the newly ataried string. Similarly, for feature 7 it
is possible to put an enemy string in atari, but leaving it the option to
escape by connecting to an alive friendly string. This would be the case for
the other (non-labeled) liberty in the example in your paper. Would you still
consider this alternative move a "kill" or do you have a strict criterium for
this (which would be more involved to check, perhaps even requiring a local
search)?
René
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
