Re: [computer-go] Fw: Compensation for handicap plays?
On Fri, 2006-12-29 at 15:28 +0100, Łukasz Lew wrote: The handicaps are set up in a way that white passes between Black's moves. Ie. he gives one point to the black N-1 times. This isn't elegant. The stones work out nicely as you say, but after a pass move the opponent has a right to pass and end the game. So to implement this correctly we have to employ ugly inconsistencies in the rules - exceptions. We impose pass moves at the start but also forbid pass moves (otherwise black always wins by passing after white passes.) I agree however that it does accomplish several interesting objectives. Personally, I'm not married to unification of rules, Japanese and Chinese are different rules and nothing will change that. I'm actually leaning back towards John Tromps suggestion and going with straight Tromp Taylor rules except for the suicide rule. The only reason I oppose the suicide rule is that it makes it possible to extend the games to ridiculous lengths - it's merely a practical consideration. And I say practical because there are bots that will do it as a matter of course. With Tromp Taylor rules, the system would work like this: 1. Standard TT playing rules - except suicide is illegal. 2. Handicap - the weaker player is black and gets to place N stones. Period.That is all there is to it. The game is scored exactly the same as it is now. The only consideration for scoring the end of the game, is knowing what komi is.That's a necessary evil and the only solution is to not have komi, but I'm not going to do that. If we feel that compensation is due, for the handicap stones, the server can add this to the komi transparently, your program doesn't need to worry about it. More than likely I would send a different komi for each handicap stone, but that's a detail your program doesn't need to know about since komi is sent at the start of the game. I believe this is the lesser of all the evils. I wanted fixed handicap, but this seems more compatible somehow with Chinese rules.The weaker programs will not benefit much from the handicap, which I don't like but it's their own fault! I suggest the weaker programs are pre-set to place the initial stones in logical places. The only other little detail is how to start the games. There are 2 reasonable possibilities: 1. Use the gtp place_free_handicap command. The server asks the program to return a list of stones to start the handicap game. 2. Just send the appropriate genmove and play commands. I'm leaning towards option 2, because it WILL NOT REQUIRE a single modification to your program if it already plays on CGOS. UNLESS, your program is incapable of playing or generating 2 moves in a row for the same color. If it doesn't, then you have a faulty GTP implementation and should fix it anyway. MY program just fills in the gaps with pass moves but you are free to handle it any way you choose that works for you. If your program is taking black you would get someting like this from the GTP channel: clear_board komi 0.5 boardsize 19 genmove black genmove black genmove black for a 3 stone handicap game. The opponent would get the corresponding consecutive play commands. I know this won't make everyone happy - but I believe it is more in the spirit of a simple logical rule-set and is what drew me to Tromp/Taylor rules in the first place. Might as well stick close to it. We can call this rule-set CGOS - which is exactly tromp/taylor without suicide. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
From what I know about rulesets, I actually prefer AGA. I believe it was designed to have the same result for both area and territory scoring. It has the pass costs one point rule. There's something special about if white passes first because then the number of stones places on the board are not equal. It also has an (N-1) compensation for handicap which seems more correct to me. Of course, the (N-1) only applies when doing area scoring; when doing territory scoring, it just works out. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lukasz Lew Sent: Friday, December 29, 2006 9:28 AM To: [EMAIL PROTECTED]; computer-go Subject: Re: [computer-go] Fw: Compensation for handicap plays? I did some research and I would like to change my vote. My criterion for perfect rules are elegance, simplicity and consistency. As You know I want unification of area and territory scoring. So here is my proposal. The unification needs that *pass* costs one point. And this is only modification needed. Agitation: You can think about pass as playing the stone not on the board but directly to the opponent's captured stones. This is elegant both under area and territory scoring because: a) On area scoring giving a stone to the opponent is 0 points as well as playing in your own territory as well as playing in opponent territory. b) On territory scoring all 3 options (opponents captured stones, yours, and opponents territories) cost one point. The handicaps are set up in a way that white passes between Black's moves. Ie. he gives one point to the black N-1 times. Please think about it. Łukasz On 12/29/06, Don Dailey [EMAIL PROTECTED] wrote: To be honest, it seems very ugly to me but it seems to be what the majority like. Apparently KGS handles it this way, the program just has to magically know what the compensation is. But that's true of any handicap system, the program has to have the correct understanding. I think we had this discussion before, but there appears to be no concise way to state the rules with the myriads of variations they entail. - Don On Fri, 2006-12-29 at 01:57 +0100, John Tromp wrote: On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote: Just to be precise: KGS does option 2 if you select chinese rules, and it also does option 1 when you select AGA rules. And to be more precise, here is how it might work: Handicap 0- komi is 7.5 and either player plays black. 1- komi is 0.5 and weaker player plays black. 2- komi is 0.5, weaker player gets black, white gets 2 points. 3- komi is 0.5 , weaker player gets black, white gets 3 points. At 2 handicap and beyond, the net effect is as if komi was increased by the number of stones handicap (but it won't be implemented that way.) Is this how everyone else understands it? That makes little sense to me. If you want to give white extra points at the end of the game, then put it in the komi. That's what it's for! So above, for 2hcap, komi will be 2.5, and for 3hcap, it will be 3.5... Why introduce 2 different komi's that need to be added? -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
On 12/29/06, Łukasz Lew [EMAIL PROTECTED] wrote: I did some research and I would like to change my vote. My criterion for perfect rules are elegance, simplicity and consistency. As You know I want unification of area and territory scoring. So here is my proposal. The unification needs that *pass* costs one point. And this is only modification needed. The handicaps are set up in a way that white passes between Black's moves. Ie. he gives one point to the black N-1 times. Please think about it. For reducing the value of handicap stones under area scoring, white should *get* an extra point for each additional handicap stone, not *lose* a point as you suggest. -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
This seems clean and reasonable to me. (Or you could just as easily have the server do the adjustment and set Komi to 3.5; that would also be consistent with TT rules). If my bot sees 2 black moves in a row, it can figure out it's in a handicap game. A bigger question to me is, how large a handicap might be encountered. Will we see Mogo playing Random with 100 stone handicap, or will excessive mismatches be disallowed altogether? Dave Hillis -Original Message- From: [EMAIL PROTECTED] On Fri, 2006- If your program is taking black you would get someting like this from the GTP channel: clear_board komi 0.5 boardsize 19 genmove black genmove black genmove black for a 3 stone handicap game. The opponent would get the corresponding consecutive play commands. I know this won't make everyone happy - but I believe it is more in the spirit of a simple logical rule-set and is what drew me to Tromp/Taylor rules in the first place. Might as well stick close to it. We can call this rule-set CGOS - which is exactly tromp/taylor without suicide. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
However, I will probably maintain the current scheduling algorithm which will make the larger mismatches fairly rare though not impossible. This will be good because it means we will still prefer non-handicap games, and I'm guessing that the vast majority of games will not be be large hendicap ones. In other words, we won't schedule randomly just because we can handicap to make it fair. Actually, how will the scheduler and ratings get handled? I saw a proposal for treating bots receiving (or giving?) handicap as a different entity. I assume you'd do a two stage match-up... One to pick the pair of bots to play and then pick the handicap. I worry a bit about the weaker programs never playing a stronger program without any handicap and possibly never benefiting from defeats of stronger programs. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
My plan was to simply use the same scheduling algorithm I currently use. I would take the weaker base player and see if handicap versions of himself more closely matches the ELO rating needed to give an even game. I assume the same method of an updated engine connecting with a new login still applies? Another way is that when a player is first created, several handicap versions spring into existence and I treat them all the same. They are all just unrated entities. It this case the scheduling algorithm would have to change - since 2 handicap players cannot play the same game. But then it's possible to have serious mismatches, which the handicap system is supposed to try to solve. That sounds like a bot can not play itself. There's also the issue that a bot can only have on opponent per connection to CGOS. A raw engine and an engine with handicap, for example, can't have games going on simultaneously. When treating the handicap versions as completely separate entities, that seems like the biggest problem to me. (That's also what led me to thinking of a two stage match-up routine) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
Okay. Don's later post does indicate that he intends to compensate for the stones. So, in the interest of being 100% clear: is this compensation included in the komi value that is sent to the client? Weston On 12/29/06, Weston Markham [EMAIL PROTECTED] wrote: Am I correct in inferring that this is also what Don Dailey has in mind, but with no compensation for the handicap stones? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
I'm considering this proposal to rate handicaps separately, still haven't decided but it's appealing. My plan was to simply use the same scheduling algorithm I currently use. I would take the weaker base player and see if handicap versions of himself more closely matches the ELO rating needed to give an even game. Until handicap versions are established of each player, I would have to make some initial assumptions about the strength of the handicap entities. One possibility is to wait for a player to get established before creating the handicap entities. Once they are established, I estimate a rating for the handicap versions and give them pretty high initial K factors. Another way is that when a player is first created, several handicap versions spring into existence and I treat them all the same. They are all just unrated entities. It this case the scheduling algorithm would have to change - since 2 handicap players cannot play the same game. But then it's possible to have serious mismatches, which the handicap system is supposed to try to solve. - Don On Fri, 2006-12-29 at 14:19 -0500, House, Jason J. wrote: However, I will probably maintain the current scheduling algorithm which will make the larger mismatches fairly rare though not impossible. This will be good because it means we will still prefer non-handicap games, and I'm guessing that the vast majority of games will not be be large hendicap ones. In other words, we won't schedule randomly just because we can handicap to make it fair. Actually, how will the scheduler and ratings get handled? I saw a proposal for treating bots receiving (or giving?) handicap as a different entity. I assume you'd do a two stage match-up... One to pick the pair of bots to play and then pick the handicap. I worry a bit about the weaker programs never playing a stronger program without any handicap and possibly never benefiting from defeats of stronger programs. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
I agree with you. Weston's post convinced me that the program should know in advance what the handicap is to be and thus sending consecutive genmove commands is not really correct technically speaking. I don't like implied compensation, but apparently it is popular and KGS does it. However, CGOS won't be doing it. I am really torn about this, but in the end I don't want to implement something I consider slightly broken just because another server does it. I think currently this falls under the category that you need to tell your program (via a command line parameter or config file) what the rules of compensation are. The rules for CGOS will be that komi by itself tells you everything you need to know about compensation. - Don On Fri, 2006-12-29 at 14:27 -0600, Nick Apperson wrote: using gen_move to place handicap stones seems unreasonable to me when there is a command intended for that purpose. The point of GTP is to make it easy to implement the protocol. Anything that either breaks programs that are written to the specification (as in using gen_move instead of free_place_handicap) or makes GTP more complicated works. Implicit handicaps are rediculous. Send it as the komi. The following steps will always make it clear to any bot that implements GTP correctly what they should do: ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
Don Dailey wrote: 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 with komi of course. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. It has already been said already, but I insist: what we need is a GTP command to tell the program what are the rules of the game. I would be glad to implement such a command, and would not care about the compensation method, then. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 28, 2006, at 10:28 , Rémi Coulom wrote: Don Dailey wrote: 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 with komi of course. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. I'd vote for 2, too. Because that's the way (apparently) KGS does it so it seems like a good idea not to have two different ways to handle things out there. Urban - -- http://bettong.net - Urban's Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFk54TggNuVCIrEyURAl8gAKCmAaCyui9h2OiiwfXjAtQxOwos3ACeK9VD Ps93rXG75Mqo5XPuu1e2ocI= =Me// -END PGP SIGNATURE- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
Markus Enzenberger wrote: would it make sense to treat players with handicap as completely different players? For example, GNU Go giving one handicap stone would be a different player and get a rating independent of GNU Go in an even game? I like that !! It would give very valuable information. Don Dailey wrote: Actually, 1 program would have at most 10 entries if I allow up to 9 handicap stones. I don't think its necessary. Two entries would be enough: handicap and even. Or maybe three, at most: given handicap, taken handicap and even. E.g. xxBot, xxBotH+, xxBotH- Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
sorry, i just realized how out of context that was. in response to X is 50kyu, Y is 300kyu, etc. 30kyu is a good bottom end. the bottom has to be somewhere, and 30kyu humans are easily beaten by most anything stronger than random play. more than 39 levels is asking quite a bit of the ranking system, given that handicap stones are expected to act somewhat linearally for small differences between ranks. the reality is that 30kyu is often just a way to refer to someone who has only minutes before learned the rules. nobody is expected to stay at 30kyu for more than, say, 2 or 3 games. a random player that doesn't fill its own eyes is a great 30kyu player in my mind. if ELO suppression is needed, a fixed anchor near the high end could always be estimated from a public-domain program that plays at, say, KGS. s. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
On 12/28/06, Urban Hafner [EMAIL PROTECTED] wrote: (...) 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. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. I'd vote for 2, too. Because that's the way (apparently) KGS does it so it seems like a good idea not to have two different ways to handle things out there. Just to be precise: KGS does option 2 if you select chinese rules, and it also does option 1 when you select AGA rules. -- nando ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
There are 3 gtp commands for handling this: fixed_handicap place_free_handicap set_free_handicap You are arguing that fixed_handicap, even though it's quite explicit, is the wrong one to use in this situation? set_free_handicap would also work - the server just specifies the points and tells both engines. It doesn't matter which we use but I would use the one I thought would avoid the most confusion. Which command does KGS use? - Don On Thu, 2006-12-28 at 15:56 -0500, House, Jason J. wrote: And your programs must be set up to just understand this if it matters. ... it will know where to put the stones initially, I disagree with this portion. One of the handicap options has the server explicitly tell the client where to put the handicap stones. For the sanity of everyone, the server should just tell the bots where to put the stones. If you meant that the engine should accept and understand that command, then I agree. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
There are 3 gtp commands for handling this: fixed_handicap place_free_handicap set_free_handicap You are arguing that fixed_handicap, even though it's quite explicit, is the wrong one to use in this situation? set_free_handicap would also work - the server just specifies the points and tells both engines. It doesn't matter which we use but I would use the one I thought would avoid the most confusion. Which command does KGS use? In my experimentation with bots on kgs, I think KGS uses place_free_handicap and set_free_handicap. I didn't even realize/remember there was a fixed_handicap command. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote: Just to be precise: KGS does option 2 if you select chinese rules, and it also does option 1 when you select AGA rules. And to be more precise, here is how it might work: Handicap 0- komi is 7.5 and either player plays black. 1- komi is 0.5 and weaker player plays black. 2- komi is 0.5, weaker player gets black, white gets 2 points. 3- komi is 0.5, weaker player gets black, white gets 3 points. At 2 handicap and beyond, the net effect is as if komi was increased by the number of stones handicap (but it won't be implemented that way.) Is this how everyone else understands it? That makes little sense to me. If you want to give white extra points at the end of the game, then put it in the komi. That's what it's for! So above, for 2hcap, komi will be 2.5, and for 3hcap, it will be 3.5... Why introduce 2 different komi's that need to be added? -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
To be honest, it seems very ugly to me but it seems to be what the
majority
like.
Apparently KGS handles it this way, the program just has to magically
know what the compensation is. But that's true of any handicap system,
the program has to have the correct understanding.
I think we had this discussion before, but there appears to be no
concise way to state the rules with the myriads of variations they
entail.
- Don
On Fri, 2006-12-29 at 01:57 +0100, John Tromp wrote:
On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote:
Just to be precise: KGS does option 2 if you select chinese
rules, and
it also does option 1 when you select AGA rules.
And to be more precise, here is how it might work:
Handicap
0- komi is 7.5 and either player plays black.
1- komi is 0.5 and weaker player plays black.
2- komi is 0.5, weaker player gets black, white gets
2 points.
3- komi is 0.5 , weaker player gets black, white
gets 3 points.
At 2 handicap and beyond, the net effect is as if komi was
increased by
the number of stones handicap (but it won't be implemented
that way.)
Is this how everyone else understands it?
That makes little sense to me. If you want to give white extra points
at the end
of the game, then put it in the komi. That's what it's for!
So above, for 2hcap, komi will be 2.5, and for 3hcap, it will be
3.5...
Why introduce 2 different komi's that need to be added?
-John
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Fw: Compensation for handicap plays?
Here's John Tromp's reply: he does not specify compensation for handicap stones - but leaves wiggle room for the players to choose such komi as they wish. - Forwarded Message From: John Tromp [EMAIL PROTECTED] To: terry mcintyre [EMAIL PROTECTED] Sent: Saturday, December 23, 2006 4:25:59 PM Subject: Re: Compensation for handicap plays? dear Terry, On 12/22/06, terry mcintyre [EMAIL PROTECTED] wrote: I've been following the discussion on the Computer Go list, where the question of implementing handicaps on the CGOS server has arisen. My reading of your Tromp-Taylor rules suggests that, when black has a handicap of n stones, no compensation is given to white. In my rules a handicap of n stones only means that white passes her first n-1 turns. It does not have any implications for komi, which can still be freely chosen. Some other systems do compensate white. http://www.britgo.org/rules/compare.html#comp discusses the topic. I must admit that I find the adjustment of komi as used in chinese and AGA rules rather ugly and prefer the SST and New Zealand approach to simply make the value of handicap stones a little larger. regards, -John __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
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/
