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?
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/
