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

Re: [computer-go] I know we disagree,but I choose to do nothing about it.

Hi Don,

On 26, Jul 2005, at 2:02 PM, drd@xxxxxxxxxxxxxxxxx wrote:
     ddoshay@xxxxxxxxxxxxxxxxx wrote:

This not only lets, but it encourages a bot with a large number of
dead stones behind enemy lines to respond to one pass with a
pass, disagree about status, and then have the chance that the
otherwise winning bot will pass again. And because there are
points to be made this way, it will happen.
Of course it will happen, if the second player is stupid enough to stop
defending himself. I really don't see the point. Whether you have the
protocol or not, a player can play out the game to the bitter end in the
hopes that the opponent will screw up, perhaps filling in his own eyes.
Indeed. But the difference is that the program that sees that the stones
are destined to die can pass many time in a row, letting the other keep
dropping stones on the board, until it sees that a single move is now
required.

I fully grant that under Chinese style counting there will be no difference
in the score, but under Japanese style counting there will be.

The difference to me is stylistic. If my program is facing a program that
will not pass, then it pleases me when my program passes repeatedly
in the endgame until it has to answer. To me that is proof that my
algorithms really understand what is alive and what is dead. You may
apply different metrics to your programs.

As we have already discussed, if you go back to the game our programs
played against each other in the 4th KGS tournament and look at the
comments being made by the people watching, they had little nice to
say about many of what they saw as useless moves by your program.
As I said before, you worked too hard on your code to have to endure that
from people who have no idea how hard it is to write a Go program.
Eventually the moves turned a full-board sweep into only a 180 point loss.
I think it was useful to see when your code saw it could make the living
group and it was useful to see where my program made its mistake.

In this case, where my program is allowed to pass as many times in a
row as it chooses to, I see the behavior of your program as tenacious,
unwilling to give up on finding a solution where it can make life in the
normal sense. I have no objection to that, and do not see why anyone
else should.

But that was different than the proposed protocol where after one pair
of passes, and the logging of a disagreement, in the next round the
first pass presents a very different evaluation function to the program:
do I try to live somewhere in the traditional sense, or do I just pass and
live everywhere. The choice that "should" be made is clear, but to me
that is not a matter of playing reasonable Go. I would not go as far as
calling it a "cheap trick" as someone else did, because it would be the
expected result of the stated rules of the tournament. I merely maintain
that it is a mistake for a tournament to have such rules.

The protocol makes it possible for COOPERATING programs to pass early. You
can never FORCE a non-cooperating program to pass early, so it's really no
use constructing scenario's where a game will get played out to the end
needlessly due to some flaw in the protocol.
As somebody who retired from the networking industry, it is my nature
to think about the consequences of protocols. When I see what I consider
to be an undesirable side effect inherent in a protocol, and I believe it
will not only give an opportunity for undesirable behavior, but will reward
it, I have to mention it.

The real difference in our arguments is that what I see as undesirable
behavior is not seen in the same light by you. You place a higher value
on automating the endgame now. I prefer thinking a little more and
implementing a protocol that does not reward behavior I do not like.

Again, I think we have exhausted the arguments and the TDs will decide
what they think is best.

Cheers,
David

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