Re: [computer-go] Anchor Player
2006/12/26, Don Dailey <[EMAIL PROTECTED]>: There are many other ways to take advantage of your opponent in chess that I consider sound if applied in a very measured and careful way. None of them call for making truly unsound moves, especially when you consider that in a losing position, all moves are unsound in some sense.Now you are in a situation of "risk management", you are looking for moves that give you the best chances of winning (a lost game) and usually, it requires a move that makes it the most difficult for your opponent. This is not quite the same as moves that make it easiest for you, which is what you look for in WON positions. There's one easy way I found to do this in Go. In handicap Go, if you're behind, set up a ko. :) Ko does complicate a game, and almost by definition, you will play it better and gain something. -- Seo Sanghyeon ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Interesting problem
I haven't really paid much attention to the previous few emails, but if it is an effort at making a weak player (as the thread started out), I shouldn't have to. Why not just randomly chose (with a programmable distribution) between making a move based on a simulation and a completely random move? This will give you adjustable play quality somewhere between the two. On 12/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: A more detailed version. 1| 208 110 63 89 93 104 106 98 117 139 117 98 106 104 93 89 63 110 208 2| 110 18868 12 17 17 22 39 22 17 17 12 868 18 110 3| 638...266454662 ...8 63 4| 896..2555444555 2..6 89 5| 938.276 10 12 12 18 12 12 106 72.8 93 6| 104 12256 11 14 16 17 23 17 16 14 11 652 12 104 7| 106 1765 10 14 27 22 21 35 21 22 27 14 1056 17 106 8| 98 1765 12 16 22 39 29 35 29 39 22 16 1256 17 98 9| 117 2244 12 17 21 29 35 37 35 29 21 17 1244 22 117 10| 139 3954 18 23 35 35 37 178 37 29 35 23 1845 39 139 11| 117 2244 12 17 21 29 35 37 35 29 21 17 1244 22 117 12| 98 1765 12 16 22 39 29 35 29 39 22 16 1256 17 98 13| 106 1765 10 14 27 22 21 35 21 22 27 14 1056 17 106 14| 104 12256 11 14 16 17 23 17 16 14 11 652 12 104 15| 938.276 10 12 12 18 12 12 106 72.8 93 16| 896..2555444555 2..6 89 17| 638...266454662 ...8 63 18| 110 18868 12 17 17 22 39 22 17 17 12 868 18 110 19| 208 110 63 89 93 104 106 98 117 139 117 98 106 104 93 89 63 110 208 Dave Hillis -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: computer-go@computer-go.org Sent: Wed, 27 Dec 2006 11:58 PM Subject: Re: [computer-go] Interesting problem Thanks Dave, - Don On Wed, 2006-12-27 at 23:50 -0500, [EMAIL PROTECTED] wrote: > File attached. And also inline below Dave Hillis antminder on KGS 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] Interesting problem
On Wed, 2006-12-27 at 21:34 -0500, Don Dailey wrote: > 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. > > I feel this would define a nice standard that is > easy to reproduce and verify experimentally and > at least would be a known quantity even 100 years > from now. > > But I'm having a difficult time creating players > who are slightly better than this at 19x19. I need > incrementally better and better players. I suspect this is quite hard problem. On 9x9 we have some of this and I suspect even there "do not fill eyes random" (PythonBrown) has not yet settled (maybe 100-200 ELO overrated). Probably too few weak players ;-) On 19x19 I think problem is much harder and required amount of intermediate players is much bigger. I'm of course interested in hearing your experimentation results. Maybe I'm wrong and it is actually feasible. My vague recollection was that random player is maybe 200 kuy, "do not fill eyes" adds 60 stones, atari detection adds about 20-30 stones, idiotbot is maybe 100 kuy, weakbot50k maybe 50 kuy. However differences between computers tend to be much bigger than when they play against humans! For example GNU Go 2.0 can give Liberty 1.0 easily 9 stones and win more than 50% of games (based on few ha9 test games), but at KGS they are rated at 10k and 14k. Even WeakBot50k is rated at 20k while latest GNU Go rated at 6k can give it numerous handicap stones (much more than 14 stones, I think it's more than 40 stones). Here is my proposal for anchor player: Use GNU Go 3.7.10 (or any enough recent with super-ko support) at level 0 and use well defined randomization on top of moves it returns. Ie. ask all_move_values (lists only moves that gnugo considers positive) and add remaining moves and then apply slight randomization so that it still plays close to original strength but is much more unpredictable than GNU Go. Example program (by blubb and me): http://londerings.cvs.sourceforge.net/londerings/go/gtpTuner/ Reasons: - reasonably strong, no need for huge amount of intermediate players - source code available - well known entity - with some randomization should be unpredictable I suspect that GNU Go without randomization is too predictable. This is very clearly case on 9x9 board and possibly on 19x19 too. -- 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
This is an interesting problem. It seems to me that the reality is that when you are talking about non-ideal play, ranking systems aren't linear. Program A could beat B which could beat C which could beat A. How would you rank those? Clearly there is going to have to be some degree of arbitrary selection. I propose convenience as the best reason for picking one anchor over another. I think a completely random player is the only other choice from a theoretically perfect player that doesn't have arbitrariness. But, by defining players relative to that anchor, we would really be measuring how effectively a program exploits a weak player rather than how good the program is. It is my opinion that it is more important to have a relative ranking system than an absolute system. - Nick On 12/28/06, Aloril <[EMAIL PROTECTED]> wrote: On Wed, 2006-12-27 at 21:34 -0500, Don Dailey wrote: > 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. > > I feel this would define a nice standard that is > easy to reproduce and verify experimentally and > at least would be a known quantity even 100 years > from now. > > But I'm having a difficult time creating players > who are slightly better than this at 19x19. I need > incrementally better and better players. I suspect this is quite hard problem. On 9x9 we have some of this and I suspect even there "do not fill eyes random" (PythonBrown) has not yet settled (maybe 100-200 ELO overrated). Probably too few weak players ;-) On 19x19 I think problem is much harder and required amount of intermediate players is much bigger. I'm of course interested in hearing your experimentation results. Maybe I'm wrong and it is actually feasible. My vague recollection was that random player is maybe 200 kuy, "do not fill eyes" adds 60 stones, atari detection adds about 20-30 stones, idiotbot is maybe 100 kuy, weakbot50k maybe 50 kuy. However differences between computers tend to be much bigger than when they play against humans! For example GNU Go 2.0 can give Liberty 1.0 easily 9 stones and win more than 50% of games (based on few ha9 test games), but at KGS they are rated at 10k and 14k. Even WeakBot50k is rated at 20k while latest GNU Go rated at 6k can give it numerous handicap stones (much more than 14 stones, I think it's more than 40 stones). Here is my proposal for anchor player: Use GNU Go 3.7.10 (or any enough recent with super-ko support) at level 0 and use well defined randomization on top of moves it returns. Ie. ask all_move_values (lists only moves that gnugo considers positive) and add remaining moves and then apply slight randomization so that it still plays close to original strength but is much more unpredictable than GNU Go. Example program (by blubb and me): http://londerings.cvs.sourceforge.net/londerings/go/gtpTuner/ Reasons: - reasonably strong, no need for huge amount of intermediate players - source code available - well known entity - with some randomization should be unpredictable I suspect that GNU Go without randomization is too predictable. This is very clearly case on 9x9 board and possibly on 19x19 too. -- Aloril <[EMAIL PROTECTED]> ___ 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?
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] 2007 KGS bot tournament schedule
Hi Don, adding silently 0.5 second per move to the clock seems a good idea and simple enough. In 9x9 10 minutes, the communication time is not really a problem as you can take 30 s security and games are quite short, but for 19x19 it can be important. Of course in a 1 minute game, you can't take a 30 s security :). Sylvain > Hi Sylvain, > > Do you think it would be useful to add 1/2 second for CGOS games? > I have long considered doing that. I would still consider it fixed > time games - I would just silently add 1/2 second to the clock for > each move as a kind of internal benefit of the doubt factor - it's > clear that some time is lost automatically even under the best > conditions. > > - Don > > On Wed, 2006-12-27 at 18:41 +0100, [EMAIL PROTECTED] wrote: > > Hi Nick, > > > > > I plan to hold another Slow tournament, once the KGS "five-minute rule" > > > but has been fixed. > > > > Good idea, this tournament have been popular. > > > > > I am also considering having a Fast tournament, with maybe a minute > > > each for 9x9, or four minutes each for 19x19. Would there be interest > > > in such an event? What board size, and time limit, would be popular? > > > > This is a good idea. Of course for the board size and time limits we have > > to test. 1 minute for 9x9 seems well suited. 4 minutes for 19x19 seems > > very quick, at least I think that MC programs would not play better than > > random at this speed :). > > I have one concern about communication time. It appeared to me that on > > KGS, MoGo can only play 4 (random) moves a second (of course it is not > > CPU time... :)). I saw that because on 19x19 one human is happy to beat > > MoGo on time simply by making the game as long as possible (almost 800 > > moves). With one minute left at the "real" end of the game, and playing > > random moves, MoGo can't manage to play the hundred moves that the human > > manages to create (by killing its one groups filling all eyes, then > > creating big empty spaces). > > > > Perhaps the duration of the game could be x minutes for the game+1 second > > per move to take into account the communication time? > > > > Anyway I think slow and fast tournaments are fun and also bring unusal > > problems which teach us interesting things. By the way, I find that the > > "normal" 19x19 tournaments with 18 minutes are already fast tournaments > > :). > > > > Sylvain > > > > ___ > > 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/ ___ 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] Interesting problem
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. Or if it is set at zero ELO all other non random bot will slowly drift toward +infinity. > > I feel this would define a nice standard that is > easy to reproduce and verify experimentally and > at least would be a known quantity even 100 years > from now. Any GPL go engine fulfill the above requirements :) Aloril did gtp patch for old gnugo, so it is possible to use gnugo-1.2 and 2.0 as weak players, and gnugo 3.7.10 at default level for stronger anchor (lower level are very poor in reading). Alain ___ 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?
>> 2. Give white N stones at end of game. (N = handicap) I vote for 2. But my reason is that 2 is the closest to some future international Go rules. I.e it allows for smooth integration of area and territory scoring. Łukasz On 12/28/06, Urban Hafner <[EMAIL PROTECTED]> wrote: -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/ ___ 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] Interesting problem
anyone who plays by the rules qualifies as 30kyu. 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?
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] Anchor Player
>> One question I have - is compensation normally given in the 1 stone >> case? > >I believe, no. > >> Also, in the case of NO handicap, what komi is normally >given in 19x19 >> Chinese? 6.5, 7.5 ??? > >It's 7.5 As best I understand it, a "one stone" game is actually normal play without komi (0.5 given to white to break ties) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Interesting problem
On Wed, 2006-12-27 at 22:53 -0500, Don Dailey wrote: > It turns out that I did not turn off all of the stuff > that strengthened the random player - so hopefully I > have much weaker players now. > > (There was a bug that made the program too strong :-) > > - Don Addendum: However, there still is a large gap between purely random and 1 simulation MC. Well over 100 ELO points. - 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 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] Interesting problem
I don't think it is possible to determine the weakest possible level. One could make a program that plays much worse than random. It would for instance rather fill its eyes than pass. I don't think any handicap will be enough to allow such a player to win. Especially when the (human) opponent knows the anti-tactics that were built into the program. Dave - Oorspronkelijk bericht - Van: Don Dailey <[EMAIL PROTECTED]> Datum: donderdag, december 28, 2006 4:23 pm Onderwerp: Re: [computer-go] Interesting problem > > > On Wed, 2006-12-27 at 22:53 -0500, Don Dailey wrote: > > It turns out that I did not turn off all of the stuff > > that strengthened the random player - so hopefully I > > have much weaker players now. > > > > (There was a bug that made the program too strong :-) > > > > - Don > > Addendum: > > However, there still is a large gap between purely random > and 1 simulation MC. Well over 100 ELO points. > > - Don > > > ___ > 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] Interesting problem
Yes, Someone mentioned random as being infinitely weak but there is no such thing.Resigning on the first move is as weak as you can get. The random player isn't really random, it doesn't fill it's eyes. There are strategies to play MUCH worse than random as you point out. I don't believe the random player is particularly easy to take advantage of. Of course it's very easy to beat, but it has no special "quirks" compared to more deterministic algorithms. That's part of the reason I feel it's a good baseline. - Don On Thu, 2006-12-28 at 18:19 +0100, [EMAIL PROTECTED] wrote: > I don't think it is possible to determine the weakest possible level. > One could make a program that plays much worse than random. It would > for instance rather fill its eyes than pass. I don't think any > handicap will be enough to allow such a player to win. Especially when > the (human) opponent knows the anti-tactics that were built into the > program. > > Dave > > - Oorspronkelijk bericht - > > Van: Don Dailey <[EMAIL PROTECTED]> > > Datum: donderdag, december 28, 2006 4:23 pm > > Onderwerp: Re: [computer-go] Interesting problem > > > > > > > On Wed, 2006-12-27 at 22:53 -0500, Don Dailey wrote: > > > It turns out that I did not turn off all of the stuff > > > that strengthened the random player - so hopefully I > > > have much weaker players now. > > > > > > (There was a bug that made the program too strong :-) > > > > > > - Don > > > > Addendum: > > > > However, there still is a large gap between purely random > > and 1 simulation MC. Well over 100 ELO points. > > > > - Don > > > > > > ___ > > 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/ ___ 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 Thu, 2006-12-28 at 16:32 +0100, nando wrote: > 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. 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? - Don > -- nando > ___ > 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?
>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? > >- Don It might be better to ask who doesn't agree rather than who does ;) What you describe is how I understand this discussion. ___ 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 Thu, 2006-12-28 at 15:36 -0500, Don Dailey wrote: > > 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? > > - Don And your programs must be set up to "just understand this" if it matters. So if it is asked to play a fixed_handicap game on CGOS of 2 stones and a komi of 0.5, it will know where to put the stones initially, it will understand that at the end of the game, the score it calculated the normal way, and that 0.5 is added to white for komi and an additional 2 points is added to white for handicap stone compensation. If the handicap is 1 stone, it is the same as a game played on CGOS today except komi is set to 0.5. Nothing else changes in this case. - 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?
> 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? - 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] Interesting problem
Le jeudi 28 décembre 2006 18:47, Don Dailey a écrit : > Yes, > > Someone mentioned random as being infinitely weak but there is no > such thing.Resigning on the first move is as weak as you can > get. > > The random player isn't really random, it doesn't fill it's eyes. > There are strategies to play MUCH worse than random as you > point out. Ok maybe one can build worst than random program, they will converge faster toward -infinity :) > > I don't believe the random player is particularly easy to take > advantage of. Of course it's very easy to beat, but it has > no special "quirks" compared to more deterministic algorithms. On CGOS 9X9 "GNUGo-1.2" is nearly 1000 ELO stronger than "Random", and on kgs gnugo1pt2 is ranked 22k, this is incredibly weak. 10-games-beginner is stronger than this ! I think it would be totally useless to try to use such a randombot for reference. The only use of random bot is for bug squashing in other engines, and test for time limit. Alain ___ 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/
