Re: [computer-go] Protocol B

[drd@xxxxxxx]

> By the way: I'm in favour of playing out the game until the very end. 

I'm in favor of playing it out to the end with NO agreement whatsoever,  pure 
Tromp/Taylor type of rules.    But I know I am asking too much and I'm not 
going to fight this battle.    There would be way too much resistance to this 
most simple and elegant solution of all.

But reading your post I see you are basically supporting a simple protocol 
AFTER the first 2 passes if there is disagreement.   You are basically 
advocating William Shuberts protocol which I'll refer to as Protocol A.

Even though I have my own clear preferences,  I'm more concerned with just 
HAVING a workable simple protocol.   I don't care what it is.

At first glance, the Protocol B does look more complicated,  but I assert that 
it is LESS complicated than Protocol A.

The pseudo code that David Doshay presented for us looks complicated because 
it includes the logic from all points of view.   It's showing ALL the 
communication between the server and the clients and ALL the irregularities 
which can happen.   But it's still just a few lines of pseudo code.

In reality,  if we take Peter McKenzie's advice and have a special genmove 
command (such as kgs-genmove_disagree) then the ONLY logic your program needs 
to have is logic NOT to pass when this command is issued.   It couldn't be 
simpler.    As I pointed out earlier, you COULD put this logic into your 
program without the special command with the simple rule, "don't pass if the 
last 2 moves were pass moves", but I agree with Peter that the command should 
be explicit.

So the way the GO program implements protocol B is exactly the same as the way 
a program would implement Protocol A.  

>>From the server point of view,  it now is (conceptually) EASIER than what WMS 
is doing now.  There is no exception coding, everything is handled uniformly 
the same and WMS doesn't even have to maintain the extra information which 
tells the server which "state" it is in. 

Don





 Thursday 28 July 2005 2:53 am, Mark Boon wrote:
> I've not really followed this discussion in full detail, but what if the
> score disagreement is in a seki?
>
> David G Doshay wrote:
> > (pass - pass)
> > ?score?
> > if agree
> >     no problem, game over
> > if disagree
> >     resolve-disagreement-genmove
> >     if reply is pass
> >         resolve-disagreement-genmove
> >         if reply is pass
> >             game over, everyone alive
> >         if reply is not pass
> >             continue game with genmove
> >     if reply is not pass
> >         continue game with genmove
>
> By the way: I'm in favour of playing out the game until the very end. If
> both agree on the score after the first two passes, fine, you can stop
> early. If there's a dispute (or if one side behaves like an ass) then
> you should have a simple rule-set that leads to an unambiguous end. That
> means until all dead stones are captured, where for Japanese type rules
> (why use them in automatic tournaments anyway?) there's a one point
> penalty for each pass. Game ends after the 3rd consecutive pass (which
> is not penalized).
>
> All other protocols seem overcomplicated and will force one party or
> another to put a lot of effort in resolving disputes. Playing until the
> end allows programs to put minimal effort into the game-ending phase if
> they wish. Those that complain saying: my program 'knows' it's dead but
> may make a mistake in capturing it will have to think again about what
> it is their program knows. If a program really 'knows' something is
> dead, the algorithm to safely capture it is fairly trivial and something
> your program will need to be able to do anyway. Your program will also
> need to be able to capture a 'dead' group when in semeai, and that is
> much more complicated. If your program can do that, it should also be
> able to capture groups at the end.
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/