Re: [computer-go] Interesting problem
On Thu, 2006-12-28 at 11:53 +0100, alain Baeckeroot wrote: > Le jeudi 28 décembre 2006 03:34, Don Dailey a écrit : > > I'm having an interesting problem - my hope is to set > > a random legal move making player (who doesn't fill > > 1 point eyes) at ELO zero. > Hmm maybe i misunderstand. It seems to me that a random player > cannot have a fixed rating (except -infinity) as it will lose > all his games against non random player. First thing: Don Dailey is talking about equivalent player to PythonBrown in 9x9 CGOS, not Random. However, for remainder of mail I'm talking mainly about actual random player. I think it has finite, albeit negative rank at 9x9 CGOS. Random statistics against PythonBrown: Result: 348/2511 Win: 13.9% It manages enough often to pass in position where weak opponent has passed and its winning ;-) On 19x19 I think win % would be significantly lower. > Or if it is set at zero ELO all other non random bot will slowly > drift toward +infinity. Actually given *enough* games "fully random including eye filling and passing moves" will win against a pro player. I did find one game where pseudorandom player (==Random at CGOS) wins against GNU Go on 5x5 board. Haven't found one in 7x7 though. I don't know about if this holds true for "non eye filling random player", sometimes it's impossible for it to randomly to play best move ;-) -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Interesting problem
Le vendredi 29 décembre 2006 10:58, Aloril a écrit : > On Thu, 2006-12-28 at 11:53 +0100, alain Baeckeroot wrote: > > Le jeudi 28 décembre 2006 03:34, Don Dailey a écrit : > > > I'm having an interesting problem - my hope is to set > > > a random legal move making player (who doesn't fill > > > 1 point eyes) at ELO zero. > > Hmm maybe i misunderstand. It seems to me that a random player > > cannot have a fixed rating (except -infinity) as it will lose > > all his games against non random player. > > First thing: Don Dailey is talking about equivalent player to > PythonBrown in 9x9 CGOS, not Random. Oh , this might change by 200 ELO ! Pythonbrown's rank depends mainly on the number of weak program between it and the anchor. > > > Or if it is set at zero ELO all other non random bot will slowly > > drift toward +infinity. > > Actually given *enough* games "fully random including eye filling and > passing moves" will win against a pro player. The *enough* is the problem. Considering the sun will burn the earth in less than 10 billion year, it is statistically impossible that a random player will win a strong dan player before the earth disapear. Paraphrasing Linux coding style: "An infinite number of monkey typing in GNU Emacs, would never make a good go program" > I did find one game where > pseudorandom player (==Random at CGOS) wins against GNU Go on 5x5 board. > Haven't found one in 7x7 though. http://homepages.cwi.nl/~tromp/go/legal.html 5x5 is 414 billion possible games, 7x7 is 8.3 x 10^22 19x19 is 2 x 10^170 Dont waste your time looking for random win on 7X7, it will ~never happen. I won't discuss this topic anymore, it already happened 1 year ago at the beginning of cgos-9x9. Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Interesting problem
Is there a reason why we need to decide, in advance, which of these many candidates should be the anchorman? If we set up a whole swathe of them, surely a week of random even games answers many of these questions and gets us well on our way to a stable basis for a 19x19 competition? Maybe after the first 100 games between each pairing we can even play at random handicaps. I realise that there are questions that even this will not answer, but at least we will have numbers to argue over. I suggest: a) everyone who has knows of a reasonable contender for the role posts a URL and details of how to set it up. b) those of us who have access to a machine that can reasonably run a go player for a week offer to host / run one of these c) once the resource constraints become clear it may be possible to host more than one player per machine. I'm more than happy to volunteer a machine week for such a purpose, and a couple of hours to set a player up. Unfortunately my own computer-go player will probably not be robustly playable in time. cheers stuart ___ 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 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 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?
On Fri, 2006-12-29 at 12:53 -0500, [EMAIL PROTECTED] wrote: > 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? This is a good question. It will be limited AT MOST 9 stones, perhaps less. I am doing a study now with Steve to explore this at 19x19 with many programs of varying strengths. 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. - Don > 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?
On Fri, 2006-12-29 at 12:53 -0500, [EMAIL PROTECTED] wrote: > 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. Yes, that's exactly the plan, I will add the compensation to komi. So you will get: even game : 7.5 komi 1 stone Handicap : 0.5 komi 2 stone Handicap : 2.5 komi 3 stone Handicap : 3.5 komi etc. If your bot sees 2 or more black moves in a row, it knows it is a handicap game - but it's ok if it doesn't know, it will still work as is. If your program plays on CGOS now it will work unmodified if "play" and "genmove" are correctly implemented. - 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?
>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?
As someone who might write programs that will play on the server, I would like to put my 2 cents in: As long as the final score is simply the difference in the number of intersections controlled by each of the players, adjusted by komi, then I will be happy. Whatever compensation for the handicap stones is decided upon, it should be accounted for in the komi value sent by the server, which should be exactly the komi value that is used to adjust the final Tromp-Taylor score. (This is clearly what Dave Hillis has in mind. Am I correct in inferring that this is also what Don Dailey has in mind, but with no compensation for the handicap stones?) If I understand correctly, kgsGtp relies on some mechanism where the compensation is implicit; so, either the komi value is not specified by the server, or the komi value that is used to adjust the final score is not the same as the value that is sent by the server. (I am not aware which is the case, since I have never used kgsGtp.) This might be incompatible with the mechanism that I describe above. If that is the case, it would be nice to have both of the GTP controller programs would have special commands (say, "kgs_rules" and/or "cgos_rules") that would be sent to the programs, in order to explicitly inform them of the rules that are in effect. (These could take version numbers of the rule sets, as arguments, in order to allow for future changes to the rules.) Aside from this, I have one very minor complaint about simply asking one player for multiple consecutive moves. In my opinion, the player should know ahead of time how many consecutive moves will be requested. The proposed method should only be used as a fallback, if there are programs that we would like to participate on CGOS, but for some reason these cannot be easily made to provide a place_free_handicap command. Even in that event, I would personally prefer to simply wrap those programs behind adapter programs that will automatically perform the translation of place_free_handicap to multiple genmove commands. (Does gtpadapter, available in gogui, already do it?) This latter point is minor. If I don't get what I want, it really won't bother me much. However, at the moment it seems to me that it should be such a small burden on developers to support the command, that it is worthwhile to ask. Weston On 12/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 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/ ___ 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?
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: 1) send a komi 2) use the handicap functions built into GTP if they are supported 3) else, use gen_move 4) send play_move to other client 5) play out the game until both players pass 6) ask engines what stones are dead 7) if they disagree, keep playing if they support that 8) when both players pass again, ask them both to score the game 9) programs can score however they want, but it should be consistent with the following: black wins if (# of black stones on board + # of spaces black has as territory) > (komi + # of white stones on board + # of spaces white has as territory) chinese rules are consistent with this approach as are japanese rules if both players pass an equal number of times. Further, the komi should include all compensation given because then programs don't need to be programmed to support various different sets of compensation. kgsGTP should either have a layer put on top or itself altered so that komi includes all compensation. This was a mistake imho in how GTP talks with KGS and it should be fixed. These are just my thoughts. - Nick On 12/29/06, Weston Markham <[EMAIL PROTECTED]> wrote: As someone who might write programs that will play on the server, I would like to put my 2 cents in: As long as the final score is simply the difference in the number of intersections controlled by each of the players, adjusted by komi, then I will be happy. Whatever compensation for the handicap stones is decided upon, it should be accounted for in the komi value sent by the server, which should be exactly the komi value that is used to adjust the final Tromp-Taylor score. (This is clearly what Dave Hillis has in mind. Am I correct in inferring that this is also what Don Dailey has in mind, but with no compensation for the handicap stones?) If I understand correctly, kgsGtp relies on some mechanism where the compensation is implicit; so, either the komi value is not specified by the server, or the komi value that is used to adjust the final score is not the same as the value that is sent by the server. (I am not aware which is the case, since I have never used kgsGtp.) This might be incompatible with the mechanism that I describe above. If that is the case, it would be nice to have both of the GTP controller programs would have special commands (say, "kgs_rules" and/or "cgos_rules") that would be sent to the programs, in order to explicitly inform them of the rules that are in effect. (These could take version numbers of the rule sets, as arguments, in order to allow for future changes to the rules.) Aside from this, I have one very minor complaint about simply asking one player for multiple consecutive moves. In my opinion, the player should know ahead of time how many consecutive moves will be requested. The proposed method should only be used as a fallback, if there are programs that we would like to participate on CGOS, but for some reason these cannot be easily made to provide a place_free_handicap command. Even in that event, I would personally prefer to simply wrap those programs behind adapter programs that will automatically perform the translation of place_free_handicap to multiple genmove commands. (Does gtpadapter, available in gogui, already do it?) This latter point is minor. If I don't get what I want, it really won't bother me much. However, at the moment it seems to me that it should be such a small burden on developers to support the command, that it is worthwhile to ask. Weston On 12/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 s
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?
On Fri, 2006-12-29 at 15:13 -0500, Weston Markham wrote: > 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? There is no implied compensation, whatever is decided is sent with the komi command. Your program won't have to guess whether to add more compensation or not. Just go by komi and it will work. - Don > 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/ ___ 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/
[computer-go] multiple entities may complicate things
Don proposed creating multiple entities for programs playing at different handicaps. That seems to complicate things. Is it possible to factor handicaps into elo-style ratings? We might start with some assumptions that, for example, 100 elo points is comparable to a one-stone handicap, test the assumptions, and make adjustments as appropriate. Given enough games, it might even be possible to answer the question of whether the handicap stones vs elo rating is best represented as a linear or nonlinear function. Some suggest that the answer would depend on the ability to use the handicap stones to good effect. There is some extensive discussion of existing rating systems here: http://en.wikipedia.org/wiki/Go_ranks_and_ratings Terry McIntyre UNIX for hire software development / systems administration / security [EMAIL PROTECTED] __ 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?
Assuming that kgsGtp's way of compensating white for the handicap stones is incompatible with CGOS's proposed handling, (in other words, if it is the case that kgsGtp sends a komi value that does not include this compensation, even though the final score will. Is this true?) I would like to briefly argue for the creation of a custom command that will be sent by CGOS in order to make its expectations explicit, simply because there would be less margin for error on the part of programs' operators. (in setting them up properly) Of course, this command will be either unimplemented or a no-op, in my own programs, simply because I think that this is already the must sensible way to handle these points. However, there may be some reason that I am not aware of why some program authors might prefer different behavior as a default. Having the command may be a benefit to them. By the way, how is this same issue handled in .sgf files? Do various programs agree on the final scores of handicap games that are recorded in .sgf, with a "KM" property specified? (Might it depend on an "RU" value that is specified?) Weston On 12/29/06, Don Dailey <[EMAIL PROTECTED]> wrote: 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 ___ 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 Fri, 2006-12-29 at 15:49 -0500, Don Dailey wrote: > 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 Revised proposal: - Extend gtp by 'rules' command If program supports rules command (seen from list_commands): rules cgos komi place_free_handicap or set_free_handicap If program does not support rules command: komi genmove black or play black Reasons: This should solve all compatibility problems and also make existing programs that implement komi, genmove and play correctly work without any modification while still allowing those that want to support more advanced handicap handling. Those that do handle place_free_handicap at KGS with implied compensation but don't support rules command would still work correctly at KGS and CGOS. If program replies with '?' error to rules command, then either abort or fall back to 'no rules supported' method. About compensation in this proposal: should work whether it is included or not. Compensation for handicap 2 and bigger: seems more compatible with rulesets being used. No compensation: a bit more elegant in some sense. Whatever is decided, CGOS rules should be defined somewhere reasonably rigorously. Extra stuff not part of proposal: - Alternative is to define many gtp commands like suicide 0|1 superko none|psk|ssk|nsk scoring area|territory Umm... seki_scoring, bent_four, repetition_result, more_than_2_passes_allowed, etc.. might be needed for completeness ;-) Actually we could even go with rules command initially and later add above like commands. It would work like this: rules cgos Engine can reply 3 ways: ? No idea about these rules and I don't know more specific commands = OK #I know these rules already ? define #please send me above gtp define rules commands (Should last one be '=' or '?' ?) -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
