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] Fw: Compensation for handicap plays?
Don Dailey wrote: I'll take a final poll - speak now or forever hold your peace! Should we: 1. Give white N-1 stones at end of game. (where N = handicap) 2. Give white N stones at end of game. (N = handicap) 3. Give white N stones except handicap 1 case. 4. Not worry about giving white anything but the appropriate handicap stones. Option 4 seems a lot cleaner and is WYSIWYG at end of game along with komi of course. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. It has already been said already, but I insist: what we need is a GTP command to tell the program what are the rules of the game. I would be glad to implement such a command, and would not care about the compensation method, then. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 28, 2006, at 10:28 , Rémi Coulom wrote: Don Dailey wrote: I'll take a final poll - speak now or forever hold your peace! Should we: 1. Give white N-1 stones at end of game. (where N = handicap) 2. Give white N stones at end of game. (N = handicap) 3. Give white N stones except handicap 1 case. 4. Not worry about giving white anything but the appropriate handicap stones. Option 4 seems a lot cleaner and is WYSIWYG at end of game along with komi of course. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. I'd vote for 2, too. Because that's the way (apparently) KGS does it so it seems like a good idea not to have two different ways to handle things out there. Urban - -- http://bettong.net - Urban's Blog -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFk54TggNuVCIrEyURAl8gAKCmAaCyui9h2OiiwfXjAtQxOwos3ACeK9VD Ps93rXG75Mqo5XPuu1e2ocI= =Me// -END PGP SIGNATURE- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 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?
Markus Enzenberger wrote: would it make sense to treat players with handicap as completely different players? For example, GNU Go giving one handicap stone would be a different player and get a rating independent of GNU Go in an even game? I like that !! It would give very valuable information. Don Dailey wrote: Actually, 1 program would have at most 10 entries if I allow up to 9 handicap stones. I don't think its necessary. Two entries would be enough: handicap and even. Or maybe three, at most: given handicap, taken handicap and even. E.g. xxBot, xxBotH+, xxBotH- Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
sorry, i just realized how out of context that was. in response to X is 50kyu, Y is 300kyu, etc. 30kyu is a good bottom end. the bottom has to be somewhere, and 30kyu humans are easily beaten by most anything stronger than random play. more than 39 levels is asking quite a bit of the ranking system, given that handicap stones are expected to act somewhat linearally for small differences between ranks. the reality is that 30kyu is often just a way to refer to someone who has only minutes before learned the rules. nobody is expected to stay at 30kyu for more than, say, 2 or 3 games. a random player that doesn't fill its own eyes is a great 30kyu player in my mind. if ELO suppression is needed, a fixed anchor near the high end could always be estimated from a public-domain program that plays at, say, KGS. s. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
On 12/28/06, Urban Hafner [EMAIL PROTECTED] wrote: (...) Should we: 1. Give white N-1 stones at end of game. (where N = handicap) 2. Give white N stones at end of game. (N = handicap) 3. Give white N stones except handicap 1 case. 4. Not worry about giving white anything but the appropriate handicap stones. I vote for 2 because that is what KGS does, and that is how I have implemented handicap in my program. I'd vote for 2, too. Because that's the way (apparently) KGS does it so it seems like a good idea not to have two different ways to handle things out there. Just to be precise: KGS does option 2 if you select chinese rules, and it also does option 1 when you select AGA rules. -- nando ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
There are 3 gtp commands for handling this: fixed_handicap place_free_handicap set_free_handicap You are arguing that fixed_handicap, even though it's quite explicit, is the wrong one to use in this situation? set_free_handicap would also work - the server just specifies the points and tells both engines. It doesn't matter which we use but I would use the one I thought would avoid the most confusion. Which command does KGS use? - Don On Thu, 2006-12-28 at 15:56 -0500, House, Jason J. wrote: And your programs must be set up to just understand this if it matters. ... it will know where to put the stones initially, I disagree with this portion. One of the handicap options has the server explicitly tell the client where to put the handicap stones. For the sanity of everyone, the server should just tell the bots where to put the stones. If you meant that the engine should accept and understand that command, then I agree. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Fw: Compensation for handicap plays?
There are 3 gtp commands for handling this: fixed_handicap place_free_handicap set_free_handicap You are arguing that fixed_handicap, even though it's quite explicit, is the wrong one to use in this situation? set_free_handicap would also work - the server just specifies the points and tells both engines. It doesn't matter which we use but I would use the one I thought would avoid the most confusion. Which command does KGS use? In my experimentation with bots on kgs, I think KGS uses place_free_handicap and set_free_handicap. I didn't even realize/remember there was a fixed_handicap command. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote: Just to be precise: KGS does option 2 if you select chinese rules, and it also does option 1 when you select AGA rules. And to be more precise, here is how it might work: Handicap 0- komi is 7.5 and either player plays black. 1- komi is 0.5 and weaker player plays black. 2- komi is 0.5, weaker player gets black, white gets 2 points. 3- komi is 0.5, weaker player gets black, white gets 3 points. At 2 handicap and beyond, the net effect is as if komi was increased by the number of stones handicap (but it won't be implemented that way.) Is this how everyone else understands it? That makes little sense to me. If you want to give white extra points at the end of the game, then put it in the komi. That's what it's for! So above, for 2hcap, komi will be 2.5, and for 3hcap, it will be 3.5... Why introduce 2 different komi's that need to be added? -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Fw: Compensation for handicap plays?
To be honest, it seems very ugly to me but it seems to be what the
majority
like.
Apparently KGS handles it this way, the program just has to magically
know what the compensation is. But that's true of any handicap system,
the program has to have the correct understanding.
I think we had this discussion before, but there appears to be no
concise way to state the rules with the myriads of variations they
entail.
- Don
On Fri, 2006-12-29 at 01:57 +0100, John Tromp wrote:
On 12/28/06, Don Dailey [EMAIL PROTECTED] wrote:
Just to be precise: KGS does option 2 if you select chinese
rules, and
it also does option 1 when you select AGA rules.
And to be more precise, here is how it might work:
Handicap
0- komi is 7.5 and either player plays black.
1- komi is 0.5 and weaker player plays black.
2- komi is 0.5, weaker player gets black, white gets
2 points.
3- komi is 0.5 , weaker player gets black, white
gets 3 points.
At 2 handicap and beyond, the net effect is as if komi was
increased by
the number of stones handicap (but it won't be implemented
that way.)
Is this how everyone else understands it?
That makes little sense to me. If you want to give white extra points
at the end
of the game, then put it in the komi. That's what it's for!
So above, for 2hcap, komi will be 2.5, and for 3hcap, it will be
3.5...
Why introduce 2 different komi's that need to be added?
-John
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
