Re: [computer-go] Congratulations to LeelaBot2 and to CzechBot
On Wed, 2008-05-07 at 09:59 -0400, Jason House wrote: > Did you know that weakbot50k and idiotbot don't actually handle the > game end at all? Once both players pass, they switch to using gnu go. Source code for weakbot50k and idiotbot is at http://londerings.sourceforge.net/go/kgs/ . This was running in last tournament and I think almost all other tournaments too. As far as I remember and now see looking at code its 100% python code and doesn't use any external programs for *anything*. It doesn't need to, removing dead stones in 'unconditionally' decided game is reasonably simple for most of time. I should probably update weakbot50k to use more recent python code which is faster, it lost on time quite often in last tournament. About losing on time against senseless moves: If simplebot lost this way completely won game I would consider it as bug in simplebot. PS. You might be confusing GnuGo1pt2, GnuGo2, LibertyBot, DrunkenGnu and similar bots with WeakBot50k and IdiotBot: those older GNU Go:s use recent GNU Go for cleanup because they either don't have code for it or would handle it wrong. Also WeakBot50k at rated games in KGS uses C code from GNU Go for speed reasons and move generation logic ported and improved from python version. Resign code in all bots which plays random games also uses C code. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Can a computer beat a human?
On Tue, 2007-01-23 at 16:53 -0500, Don Dailey wrote: > It's obvious that you can't program a 10 instruction per second computer > to beat a human - so it's also clear that there would be some minimum > level of hardware required. Obvious? You have proof of that? ;-) Don't underestimate God, there might exist some really really really clever mathematical way to select enough good moves with 1000 instructions on 19x19 board to beat a pro player. > > I could make a guess, but I certainly don't trust my intuition here. > My guess is that God could program a core 2 duo system of today to > beat a strong human. That is probably safe bet. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] January KGS bot tournament results
On Mon, 2007-01-08 at 13:56 -0500, House, Jason J. wrote: > It's been a very long time since housebot got the final status list > wrong at the end of a game. I'll check with "ujh" who was running the > bots to see if we have a kgs log of what happened at the end of that > game. > By default, housebot 0.4 plays until all stones are decided by > Benson's algorithm for unconditionally safe stones. Otherwise, > housebot plays in the uncertain regions until it kills something or > leaves itself in atari. That makes final status list very easy to > answer. This is also why it filled its eye in the seki later on. > There are a few scenarios where that method leads to a position it > can't score correctly, but they're very rare and didn't come up in the > idiotbot game. Going into cleanup (at all) seems rather strange to me > since I have faith in both housebot 0.4 and IdiotBot's handling of the > final status list dead. > Alas, this is all speculation until I can see the logs. Based on kgsGtp docs if HouseBot doesn't implement kgs-genmove_cleanup it will claim all stones as alive. This is change from KGS2 tournaments. In short: 1) You must support both kgs-genmove_cleanup and final_status_list or 2) You must capture dead opponent stones by playing before you pass (like at CGOS). kgsGtp docs say this: KGS and Tournament Games Tournament games are similar to ranked games but even stricter. Tournament play with kgsGtp is designed with a goal of allowing GTP vs. GTP play with no human intervention and no scoring disputes. Because of this, it is required that engines prove the status of dead groups, either with the kgs-genmove_cleanup command or by playing until all dead stones are removed from the board. In tournament play, when the game ends, there are two possibilities: Engine Supports kgs-genmove_cleanup and final_status_list: The engine will be queried as normal at the end of the game. If the engine disagrees with the stones that the opponent marks dead, then play will continue with the genmove requests replaced by kgs-genmove_cleanup. After the engine passes, it will be assumed that all stones in play are alive. This is the same as normal ranked play. Engine is Missing Support for kgs-genmove_cleanup and/or final_status_list: In this case the engine is not capable of resolving disputes after scoring, so the engine must resolve all disputes during play. The engine will claim that all stones on the board (by either player) are alive. If the opponent disagrees, then kgsGtp will continue to insist all stones are alive. Thus, if two engines that both support the cleanup system play, any disagreements will be resolved by continuing play; after the cleanup phase, all stones will be considered alive by both engines. If one that supports cleanup plays one that does not, the engine that supports cleanup will be forced to play on until it also considers all stones alive. If neither engine supports cleanup, then disagreement is not possible, since both engines must play until all dead stones are removed. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] January KGS bot tournament results
On Mon, 2007-01-08 at 16:29 +, Nick Wedd wrote: > My write-up of yesterday's KGS online computer Go tournament is now > available, at http://www.weddslist.com/kgs/past/22/index.html > > Congratulations to MoGoBot, undefeated winner of both divisions! > > Nick "HouseBot obtained a won position against IdiotBot. However it does not implement the kgsGtp clean-up instruction, so IdiotBot was able to claim that its dead stones were alive and win the game." IdiotBot seems OK in disputed position, from logfile: FINEST: Got successful response to command "final_status_list dead": = N1 M11 C3 H10 B1 M8 C9 N6 F13 A9 M2 A13 M4 Actually I think all stones are simply assumed alive after cleanup phase. I think this is done by kgsGtp and bot has no control over this. >From log file: INFO: Cleanup mode has ended by passes. It will be assumed that all dead stones have already been removed. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Fw: [computer-go] Re: Interesting problem
On Thu, 2007-01-04 at 09:08 -0800, steve uurtamo wrote: > there's a nice rule of thumb that says that you should only > play moves whose outcome results in your opponent playing > *what you think is the best move*. there's simply nothing > more irritating than someone attempting an unreasonable > invasion at the end of a game in order to try to turn a loss > into a win. either they're assuming that you're unable to > respond correctly, or hoping that you'll run out of time. I'll claim that unreasonable invasions are bigger problem under Japanese rules than under Chinese rules. 3 examples of silly invasions and reactions to them. Example 1: WeakBot50k vs some single digit kuy player at KGS2 time (now WeakBot50k is 20k, but at KGS2 time it was < 30k). WeakBot50k is very weak bot, but opponents kept passing and sometimes needed some time to think whether to pass or respond. Surprisingly often opponent passed when should not and WeakBot50k lived or increased live group size. So my conclusion is that this was stressful for stronger opponent and too often failure. Example 2: WeakBot50k vs me: It doesn't take that many moves to achieve unconditionally alive status so games end much faster and easier than with example 1. Of course this is attributed to WeakBot50k knowing when all is unconditionally decided and then passing. Still much easier way to end game. (currently running WeakBot50k version resigns when it gets too much behind as decided by 100 random games) Example 3: Me vs another human with 7:31 sudden death game with Chinese rules. Game was over and there was not much time left on either of our clocks. Opponent tries silly invasions, but I continue simplify positions and thus being able to answer faster and faster and eventually position was mostly unconditionally alive. At that point opponent resigned position being dead simple and having less time on clock. I used less time than opponent and eventually could have passed for free. Had game been under Japanese rules I would have been 'forced' to think whether reply was needed and thus think a lot longer time for replies and possibly lost on time because reply would have been needed probably too often. Conclusion: Under Chinese rules and limited time player can end game easier and faster than under Japanese rules when opponent tries silly invasions. Japanese: harder and more stressful Chinese: easier and less stressful Also being able to simplify and achieve unconditional life as fast as possible is a skill 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?
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/
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
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?
On Wed, 2006-12-27 at 19:16 -0500, Don Dailey wrote: > This is a mess. I'll need to make a decision soon as I'm already > testing the 19x19 server - getting some baseline data so that I > can then estimate the proper handicap assignments. > > I don't know if this will be an issue for many programs, but the > Monte Carlo programs will have to figure it correctly or they will > suffer. > > Personally, I like the simple SST/New Zealand approach - no special > compensation. It's more of a WYSIWYG approach. > > Magnus suggests using compensation to make it more KGS compatible. > > But we are not trying to keep the handicap traditional, we are actually > going to let the games and the results determine handicap and use > ELO. So there is no argument for keeping it Japanese compatible. > > I'll take a final poll - speak now or forever hold your peace! > > Should we: > > 1. Give white N-1 stones at end of game. (where N = handicap) > 2. Give white N stones at end of game. (N = handicap) > 3. Give white N stones except handicap 1 case. > 4. Not worry about giving white anything but the appropriate > handicap stones. > > Option 4 seems a lot cleaner and is WYSIWYG at end of game along > witPlacing 2 handicap stones for playerW and playerB: Options 1 and 2 using standard handicap gtp commands would subtly break KGS compatibility which I think is bad idea. I vote against that. I see 3 different options from "coding bot viewpoint". (named as 4a, 4b and 3) Option 4a - Place handicap stones by genmove/play commands including pass move for white. No extra handicap compensation. Handicap 2 example: playerB: genmove black playerW: play black [result of above genmove] playerW: play white PASS playerB: play white PASS playerB: genmove black playerW: play black [result of above genmove] playerW: genmove white playerB: play white [result of above genmove] playerB: genmove black ... continued as normally. Good points: Simple and possibly no changes in clients needed (including cgosGtp.tcl). Colors alternate as some clients might except them to do. Bad point: Breaks 2 passes ends game paradigm. Example: black sees white passed and "if I pass now game ends as win for me" and decides to pass too. Option 4b - Place handicap stones by genmove/play commands but no pass moves for white. No extra handicap compensation. Handicap 2 example: playerB: genmove black playerW: play black [result of above genmove] playerB: genmove black playerW: play black [result of above genmove] playerW: genmove white playerB: play white [result of above genmove] playerB: genmove black ... continued as normally. Good point: Simple and possibly no changes in clients needed (including cgosGtp.tcl). Keeps 2 passes ends game paradigm. Bad point: Some clients might assume consecutive moves alternate colors. Option 3 Use gtp standard place_free_handicap and set_free_handicap when handicap is 2 or bigger and use same handicap compensation as KGS uses under chinese rules. I think its option 3 "Give white N stones except handicap 1 case." Good point: Standard way to place handicaps and client knows its handicap placement and not normal genmove. Bad points: Needs support for those in clients and cgosGtp.tcl Need to clearly define/state handicap compensation possibly outside gtp protocol. More complex. My vote is for option 4b. I think breaking alternate coloring of moves is less worse than breaking 2 passes ends game and its more simple than option 3. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Slow KGS computer Go Tournament
On Sun, 2006-12-17 at 18:25 -0500, Don Dailey wrote: > server.host=goserver.gokgs.com > server.port=2379 These lines are not needed. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] End of games in KGS
On Mon, 2006-11-27 at 11:10 +0100, [EMAIL PROTECTED] wrote: : > Looking at the games against humans, I saw that sometimes the human does not > accept the dead strings MoGo proposes and then allow a score to the game > which is not the real score. I have undersood that if the 2 opponents do not > agree on the dead string, then "kgs-genmove_cleanup" was called until the > end, and after all strings will be counted as alive. > So is it a MoGo bug, or the human has the right to choose the dead strings as > he want ? And is this different in ranked game, and tournaments ? I know > there were some problems in past KGS tournaments with the dead strings > command, but I think now it is solved. kgs-genmove_cleanup is not sent on free games, whatever humans proposes is accepted. So on non tournament 9x9 and 13x13 games human can always mark all computer stones as dead. As far as I know kgs-genmove_cleanup is used only in rated games and recently added to computer tournament games. : -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] November KGS online results
On Tue, 2006-11-07 at 10:20 -0500, House, Jason J. wrote: > I believe there's an alternate to option #3. Force the bot to play > only one game at a time and respawn. If leaving by timeout doesn't > cause an exit from kgsGtp, it does at least cause a call to > kgs-game_over which can cause the bot to exit. Bot does not exit from KGS, it just leaves game and starts waiting for another. So next thing seen in the log file is start of the next game. >From kgsGTP viewpoint opponent escaped. Normally it would mean just that but in tournament games clock keeps running and the bot whose kgsGTP got bored loses on time. > > -Original Message- > It seems that GoComputer was away for more than 5 minutes which makes > opponent > bot to leave game permanently even in tournament. > This means that there must be human in attendance to > reconnect bot before it runs out of time :-( > > There are 3 alternative solutions to this problem: > 1) kgsGtp is fixed so that it does not leave tournament games even when > opponent bot is absent for more than 5 minutes. > > 2) If opponent crashes for more than 5 minutes or is not present for 5 > minutes at start of game and thus makes its opponent to leave game and > lose on time: Crashing or initially absent opponent should forfeit > game. > > 3) Bot authors make some code that monitor kgsGtp.log-0.log file for > "Leaving game." -message and then deliberately exit bot. This would > make > bot disconnect from server and with rejoin script around calling kgsGtp > bot would then reconnect and rejoin game. Alternatively human is > following game and makes it reconnect. > ___ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] November KGS online results
NG: Opponent has left game. Will give them 5 minutes to return. Nov 5, 2006 9:35:00 PM org.igoweb.kgs.client.gtp.GtpClient d FINEST: Command sent to engine: genmove b Nov 5, 2006 9:35:00 PM org.igoweb.kgs.client.gtp.GtpClient d FINEST: Got successful response to command "genmove b": = D4 Nov 5, 2006 9:35:00 PM org.igoweb.igoweb.client.gtp.P a FINEST: Submitting move d4 to server Nov 5, 2006 9:35:00 PM org.igoweb.kgs.client.gtp.GtpClient d FINEST: Command sent to engine: time_left b 779 0 Nov 5, 2006 9:35:00 PM org.igoweb.kgs.client.gtp.GtpClient d FINEST: Got successful response to command "time_left b 779 0": = time not managed Nov 5, 2006 9:35:00 PM org.igoweb.igoweb.client.gtp.P h FINE: Opponent has returned. Nov 5, 2006 9:35:01 PM org.igoweb.igoweb.client.gtp.P i WARNING: Opponent has left game. Will give them 5 minutes to return. Nov 5, 2006 9:35:03 PM org.igoweb.igoweb.client.gtp.P i WARNING: Opponent has left game. Will give them 5 minutes to return. Nov 5, 2006 9:40:01 PM org.igoweb.igoweb.client.gtp.P h WARNING: Opponent has not returned. Leaving game. Nov 5, 2006 9:40:01 PM org.igoweb.kgs.client.gtp.GtpClient c FINE: Game ended. Starting another. Nov 5, 2006 9:40:01 PM org.igoweb.kgs.client.gtp.GtpClient b FINER: No games to join. I'll just sit and wait. Nov 5, 2006 9:40:03 PM org.igoweb.igoweb.client.gtp.P h WARNING: Opponent has not returned. Leaving game. Nov 5, 2006 10:04:00 PM org.igoweb.kgs.client.gtp.GtpClient a FINE: Tournament game found, will join Nov 5, 2006 10:04:00 PM org.igoweb.kgs.client.gtp.GtpClient c FINER: Joined game Nov 5, 2006 10:04:00 PM org.igoweb.igoweb.client.gtp.P FINE: Starting game as black against HBotSVN PS. cc: to wms because of bug/miss feature in kgsGtp. -- Aloril <[EMAIL PROTECTED]> ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
