[computer-go] Fw: Compensation for handicap plays?

[Aloril]

On Wed, 2006-12-27 at 19:16 -0500, Don Dailey wrote:
> This is a mess.   I'll need to make a decision soon as I'm already 
> testing the 19x19 server - getting some baseline data so that I
> can then estimate the proper handicap assignments.   
> 
> I don't know if this will be an issue for many programs,  but the
> Monte Carlo programs will have to figure it correctly or they will
> suffer.
> 
> Personally,  I like the simple SST/New Zealand approach - no special
> compensation.   It's more of a WYSIWYG approach.
> 
> Magnus suggests using compensation to make it more KGS compatible.
> 
> But we are not trying to keep the handicap traditional, we are actually
> going to let the games and the results determine handicap and use
> ELO.   So there is no argument for keeping it Japanese compatible.
> 
> I'll take a final poll - speak now or forever hold your peace!
> 
> Should we:
> 
>   1.  Give white N-1 stones at end of game.  (where N = handicap)
>   2.  Give white N stones at end of game.  (N = handicap)
>   3.  Give white N stones except handicap 1 case.
>   4.  Not worry about giving white anything but the appropriate
>       handicap stones.
> 
> Option 4 seems a lot cleaner and is WYSIWYG at end of game along
> witPlacing 2 handicap stones for playerW and playerB:


Options 1 and 2 using standard handicap gtp commands would subtly break
KGS compatibility which I think is bad idea. I vote against that.

I see 3 different options from "coding bot viewpoint".
(named as 4a, 4b and 3)

Option 4a
---------

Place handicap stones by genmove/play commands including pass move for
white. No extra handicap compensation.

Handicap 2 example:

playerB: genmove black

playerW: play black [result of above genmove]
playerW: play white PASS

playerB: play white PASS
playerB: genmove black

playerW: play black [result of above genmove]
playerW: genmove white

playerB: play white [result of above genmove]
playerB: genmove black

... continued as normally.

Good points:
Simple and possibly no changes in clients needed (including
cgosGtp.tcl).
Colors alternate as some clients might except them to do.

Bad point:
Breaks 2 passes ends game paradigm.
Example: black sees white passed and "if I pass now game ends as win for
me" and decides to pass too.

Option 4b
---------

Place handicap stones by genmove/play commands but no pass moves for
white. No extra handicap compensation.

Handicap 2 example:

playerB: genmove black

playerW: play black [result of above genmove]

playerB: genmove black

playerW: play black [result of above genmove]
playerW: genmove white

playerB: play white [result of above genmove]
playerB: genmove black

... continued as normally.

Good point:
Simple and possibly no changes in clients needed (including
cgosGtp.tcl).
Keeps 2 passes ends game paradigm.

Bad point:
Some clients might assume consecutive moves alternate colors.

Option 3
--------

Use gtp standard place_free_handicap and set_free_handicap when handicap
is 2 or bigger and use same handicap compensation as KGS uses under
chinese rules. I think its option 3 "Give white N stones except handicap
1 case." 

Good point:
Standard way to place handicaps and client knows its handicap placement
and not normal genmove.

Bad points:
Needs support for those in clients and cgosGtp.tcl
Need to clearly define/state handicap compensation possibly outside gtp
protocol.
More complex.


My vote is for option 4b.
I think breaking alternate coloring of moves is less worse than breaking
2 passes ends game and its more simple than option 3.

-- 
Aloril <aloril at iki.fi>