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 <[EMAIL PROTECTED]> _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
