Re: [computer-go] Handtalk's Chen Zhixing
I read it on Chinese news and forums as well. On Fri, Nov 21, 2008 at 12:57 PM, Ian Osgood [EMAIL PROTECTED] wrote: The following was posted on Sensei's Library: Prof. Chen passed away at Oct 12, 2008, at the age of 77. Can anyone confirm or deny? Ian ___ 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] On ranks 2 and 3 of 9x9 in Beijing
without seki, B + W = 81, so B - W is always an odd number. 6.5 and 7.5 actually are different in case B - W = 7. On Thu, Oct 2, 2008 at 3:16 PM, Antonin Lucas [EMAIL PROTECTED]wrote: On Thu, Oct 2, 2008 at 6:13 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote: I'd have some preference for playing the decisive game with komi = 6.5, but apparently thats not possible on KGS. I think with komi = 7.5 white is scoring very high (too high?) in the top games. Aren't 6.5 and 7.5 komi in area counting essentially equivalent, save for a few seki cases ? ___ 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] Article By Zhou Junxun 9p on the MoGo Matches
http://post.weiqi.tom.com/BA000A6427.html in Chinese. A quick summary on the games -- He very rarely played 9x9 games. On the first 9x9 game after the 11th move, to his shock he figured he was already lost. But then he spent 5 minutes to design a Hamete to win the game back. The second game was easy. As for 19x19 game, he figured he had a sure win in about 30 moves. The following is the google translation of the excerpt on the two 9x9 games. The first game under the MOGO in the first 11 hands (black sixth-step) I have found that natural shock defeat (at the time of the heart is really very shocked ..) later took five minutes to calm feelings. How to start designing a computer can not be cheated easily see through and reversed. Article 20, I started out under the Council of the wins (also a Super cheat) (MOGO heard before the computer is in the Go Changhao Li. He is very good at only half-won Purpose of the final model) MOGO long after the test was the next out and I expect the same in the hand-shun. (MOGO if the first fight all the way to eat in the upper under accordance with the actual combat. This is the last game I lost half a head) I was very lucky The first set victory. Authority in the first place for me to experience the way the board has nine more. Black on the second set I was relatively easy victory. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] reminder, there is another possible computer go contest in Taizhou
If I guess it correctly, it is probably not professor Liu's decision, rather the sponsor's request the tournament be held in their own city instead of Beijing, as there are cash prizes involved. On Wed, Aug 27, 2008 at 5:29 AM, Rémi Coulom [EMAIL PROTECTED]wrote: Erik van der Werf wrote: I already booked my flights; Steenvreter will only participate in the official ICGA events. Personally I think it is bad to have 3 competing tournaments so close to each other. I must say that I'm quite puzzled by the behavior of the local organizers in China. In my opinion, instead of running yet another tournament, professor Liu should have tried to supported the ICGA events with sponsorship for the Go competitions just as was done for the Chess tournament. Erik It is all the more amazing as Professor Liu is also an official member of the organizing committee of the Computer Olympiad. And when I talked to Mark Winands and David Levy about TaiZhou, they replied to me that they were not aware of that tournament! The TaiZhou organizers simply collected e-mail addresses of participants registered to the Olympiad to announce their tournament. Maybe you were not registered yet when they did it. Rémi ___ 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] no anchor on 13x13 cgos since yestday
___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Program don't start playing on CGOS
I also had a similar experience a couple of days ago. On one game, my bot generated the first move, but the opponent did not respond. So my bot was awarded with a win on time. Then my bot did not receive any new message from the server and it was assigned with a loss on time on the next game. Apparently the server thought the game was on. This was on 13x13 server. On Sat, Aug 9, 2008 at 9:19 AM, Don Dailey [EMAIL PROTECTED] wrote: Ben, I am having the same exact problem, so I don't think it's anything you are doing wrong. It seems to have something to do with idling a long time and it only seems to affect certain networks.On my own machine and internet connection it never happens. But I have access to a machine where it's happening. I am also interested if anyone else has run into this and perhaps solved it or has an idea what is going on. - Don On Sat, 2008-08-09 at 08:39 +0200, Ben Lambrechts wrote: If my program has to wait to long before it gets a game, the console don't send commands to my program. I tried all I could think about: I used the tclkit from Equi4 and tried ActiveTcl. I tried to create a .bat file and run it in the normal console and PowerShell. Can someone help with this problem please? With kind regards, Ben I followed the instructions from http://www.mail-archive.com/computer-go@computer-go.org/msg04946.html and correctly set the server and port in the tcl-script to cgos.boardspace.net and 6819 C:\CGOS tclsh85 cgos3.tcl GtpTest3 MyGtpProgram.exe 08:00:20C-E list_commands 08:00:22E-C boardsize 08:00:22E-C clear_board ... 08:00:22E-C undo 08:00:22E-C version 08:00:22recieved full response to list_commands 08:00:22Engine uses time control commands 08:00:23Successful connection to CGOS server 08:00:23S-C protocol 08:00:23C-S e1 CGOS tcl engine client 1.2 Windows-x86 by Don Dailey 08:00:23S-C username 08:00:23C-S GtpTest3 08:00:23S-C password 08:00:23C-S By now a game is started and my program don't get commands from the console, but it seems that the console also don't get commands from the server... If I try to restart the start-script I get additional lines: 08:21:50S-C Error: You are already logged on! Closing connection. 08:21:50Connection to server has closed. Will try to reconnect shortly And most of the time, my program loses on time because of this. But sometimes it suddenly connects and plays its game. ... 08:36:38C-E genmove w 08:36:38E-C = A10 08:36:38C-S A10 08:36:38S-C play b PASS 1199968 08:36:38C-E play b PASS 08:36:38E-C = 08:36:39S-C genmove w 300024 08:36:39C-E time_left w 300 0 08:36:39E-C = 08:36:39C-E genmove w 08:36:39E-C = J4 08:36:39C-S J4 08:36:39S-C play b PASS 1199968 08:36:39C-E play b PASS 08:36:39E-C = 08:36:39S-C genmove w 300024 08:36:39C-E time_left w 300 0 08:36:39E-C = 08:36:39C-E genmove w 08:36:39E-C = pass 08:36:39C-S pass 08:36:40S-C gameover 2008-08-09 W+40.5 08:36:40C-S ready And then I have just the same problem, if it has to wait to long before the other games are finished, it doesn't start in his next game. ___ 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] Re: Computer Go tournament at EGC, Leksand, Sweden
I have tried Fedora Live USB Creator. It is very easy to create a bootable fedora on usb from windows machine. It literally requires only one click. Here is the link -- https://fedorahosted.org/liveusb-creator On Tue, Aug 5, 2008 at 10:52 AM, Basti Weidemyr [EMAIL PROTECTED] wrote: Hi A note from the ORGANIZERS: We are trying to prepare USB-sticks with Linux to boot the computers from. It seems we will have 3 sticks - for Fuego, for Steenwreter and for for example HouseBot. Oddly enough the computers will not boot from CD. We have no clues. :) It will turn out later today whether it works or not, but booting linux from a USB-stick worked fine for Gunnar Farnebäck. Best regards Basti Weidemyr sestir On Aug 5, 2008, at 3:38 PM, Jason House wrote: I'm not physically attending the EGC. In order to participate, I needed to provide a windows executable and have someone operate the bot on my behalf. I probably should have taken advantage of the offer to use a Linux box, but I figured I'd make it easier on the organizers :) On Tue, Aug 5, 2008 at 9:28 AM, Don Dailey [EMAIL PROTECTED] wrote: On Tue, 2008-08-05 at 08:30 -0400, Jason House wrote: I have to withdraw from this tournament. I don't have a windows computer, and getting access to one with the ability to install tools has been tougher than anticipated. Why do you need a windows computer? It's my understanding that they already supply windows Vista computers for you. And can't you bring the software tools you need to install with you on a pen drive or on cdrom? - Don On Thu, 2008-07-17 at 14:53 +0100, Nick Wedd wrote: The European Go Congress (see http://egc2008.eu/en/congress/index.php ) will be held in Leksand, Sweden from July 26th to August 9th. On Wednesday August 6th it will include a Computer Go event (see http://www.computer-go.info/egc2008/). Entry to this is free. If you would like to enter but cannot be there yourself, it should be possible for you to send in your program, and I will try to find an operator for it. According to my records, entries so far are: 19x199x9 CrazyStonepossible possible FirstGo yes yes GNU Goprobable probable HouseBot no yes Leela probable yes Mango possible possible Many Faces of Go yes no Steenvreter no yes Toaster no possible TSGo probable no Tuuppari yes yes valkyria possible possible Wei2Goprobable no I expect this table needs correcting and bringing up to date. Corrections and updates may be posted to this list or sent to me privately, as you prefer. Late entries are also welcome. The programs will be run on Windows Vista PCs in Leksand, connected to KGS, where the games will be played. Of the programs listed above, TSGo (by Ivo Tonkes) and Tuuppari (by a team of Finnish programmers) have never, so far as I know, competed in a KGS tournament. I would like both those programs to play in a trial tournament on KGS, to ensure that they are correctly configured for tournament play, rather than finding out that they aren't on the day of the event. I am willing to set up such a trial tournament whenever requested - it will use very short time limits, and no-one will care who wins, the purpose will be to test their handling of the tournament settings. However I suspect that neither of these programs yet has its Windows version in a presentable state. I hope to hear soon from Ivo Tonkes and Mika Urtela about this - if I don't, I shall assume that they aren't reading this list, and email them privately. I owe two pints of beer to the GNU Go team. I expect to deliver these to Gunnar, if he is there to operate GNU Go. Gunnar will also be speaking on computer Go, after the tournament. Nick ___ 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Ladders and UCT again
Ladder read should be helpful in the open space. But when the surrounding area is not full of space, the ladder play could hurt the eyes. for example below in the corner. b is better than a. By ladder reading, it would play at a, and the defender answer at b, leaves the attacker no eye in the corner. *|.#.* *|b..* *|.##aO..* *---* On Fri, Aug 1, 2008 at 1:37 PM, Mark Boon [EMAIL PROTECTED] wrote: On 1-aug-08, at 14:15, Peter Drake wrote: On Aug 1, 2008, at 8:08 AM, Mark Boon wrote: The neighbours of the last move come in the picture because usually it's only the last stone played that can be escaping a ladder and it's the neighbours of the last move that could have been put into atari. Nothing to do with the additional complexities Don mentioned. Let me give a specific example. Suppose that, during a playout, the tree leads us to this position, with O to play: *.* *...OO* *..O##a...* *...Ob* *c* *.* *.* *.* *.* Having reached the frontier of the tree, we now finish the game using Monte Carlo with a ladder reader. The last stone played, to the left of a, is trapped in a ladder, but can escape if not chased. Our ladder reader therefore suggests O play at a. For the next move in the playout, if # only reads ladders from the last move played, it will see that the O stone at a is not in a ladder, so move is suggested. The playout now turns completely random, and it's a coin toss as to whether the group will escape. That's it. That's all there's to it. (Assuming you meant to write so no move is suggested.) If we also search stones next to the last stone played, things only get slightly better. # sees that its stones are in a ladder from which they cannot escape, so it doesn't suggest b. Exactly. This is the neighbour part. In case 'a' was played by accident and # can escape it will suggest 'b'. If we tell it to play a ladder breaker in such situations, it might play c, which is fine. However, on O's next turn, c is not in a ladder, nor is any stone next to c, so no move is suggested. Specifically, O does not make the vital capture at b. I don't bother with ladder-breakers. It seems too expensive to search every point on the board for ladders. What to do? What you could do is keep track of stones with one or two liberties and keep them in a list. But I found it's still too expensive for relatively little gain in strength, although I'd have to admit not yet having exhausted all possibilities here. What was the question again? ;-) Mark ___ 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] kartoffel on cgos
kartoffel on cgos has a high winning ratings against strong bots, but losing to weak bots. Its rating is only 1575, but has higher than 50% against bots over 2200 ratings. Anybody knows what algorithm it uses? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: kartoffel on cgos
Seems it has a serious bug on end game against weak bots. Most of its losing games against weak bots lost on illegal move. On Fri, Jul 25, 2008 at 9:36 PM, John Fan [EMAIL PROTECTED] wrote: kartoffel on cgos has a high winning ratings against strong bots, but losing to weak bots. Its rating is only 1575, but has higher than 50% against bots over 2200 ratings. Anybody knows what algorithm it uses? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Graph history interaction
I had the same issue in UCT tree. What I did is to check if the current node is a ko move, then compare it with its latest 6 ancestors. If any match is found, then consider the move is a loss. So it cuts off the infinite loop. On Fri, Jul 11, 2008 at 12:08 PM, Peter Drake [EMAIL PROTECTED] wrote: My sense is that most programs ignore superko except for checking right before a real move (as opposed to a playout move) is played. The way out of the infinite loop is to set a maximum number of moves in a playout; abort the playout if you reach this threshold. On Jul 11, 2008, at 9:03 AM, Jason House wrote: I tracked down a rare hang/crash in my bot and I'm curious how others handle this. I use simple ko state as part of my hash lookup, but I don't use super ko. I can't store the whole graph history because then there would be no transpositions at all. I can't really update legal moves to exclude super ko because the super ko legality changes based on how a node is reached. In particular, a deterministic algorithm like UCT can get caught in an infinite loop. My random playouts may take a bit longer from super ko, but it gets quickly resolved. Sent from my iPhone ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Peter Drake http://www.lclark.edu/~drake/ http://www.lclark.edu/%7Edrake/ ___ 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] Congratulations to AyaMC and to StoneGrid!
After I review the game, it is hard to say ManyFaces made a mistake at move 60 or around, since the white group at the lower left corner has a flaw. It is a sente for black to settle its F1 group. If white takes two steps to take the ko and A7 group, then black can settle down the F1 black group and kill the white E2 group by D2 then E1. Thus white cannot win the ko. During the game I thought the ManyFaces made a mistake. But it seems I was wrong. Another comment on the game ending, StoneGrid responded to the final_status_list dead correctly. But ManyFaces only responded with one new line when the list is empty. On Mon, Jun 16, 2008 at 12:58 PM, Jason House [EMAIL PROTECTED] wrote: Is it possible to show the board for the round 1 open division game? You refer specifically to a choice made at move 60... Also, the processor description for HBotSVN is incorrect. Rounds 1-6 were through a virtual machine on a box with a 2GHz Intel Core Duo.Rounds 7-9 was running native on a Dual Core T2330 (1.6GHz/533Mhz FSB/1MB cache). It also turns out that rounds 7-9 were run with a newer version of the bot. IIRC, they ran with HouseBot 0.7 r763 while the earlier rounds were run with HouseBot 0.7 r761. On Mon, Jun 16, 2008 at 12:33 PM, Nick Wedd [EMAIL PROTECTED] wrote: AyaMC and StoneGrid were the winners of yesterday's KGS bot tournament, both undefeated, with 6/6 and 9/9 wins respectively. My report is at http://www.weddslist.com/kgs/past/39/index.html It is longer than usual, because I found quite a few of the games interesting. Nick -- Nick Wedd[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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Congratulations to AyaMC and to StoneGrid!
Nick, Thanks for all your work. John On Mon, Jun 16, 2008 at 1:56 PM, Nick Wedd [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Jason House [EMAIL PROTECTED] writes Is it possible to show the board for the round 1 open division game? You refer specifically to a choice made at move 60... I have added a diagram. But it turns out my analysis was wrong, I now think that by move 60 White had no way of winning. Also, the processor description for HBotSVN is incorrect. Rounds 1-6 were through a virtual machine on a box with a 2GHz Intel Core Duo. Rounds 7-9 was running native on a Dual Core T2330 (1.6GHz/533Mhz FSB/1MB cache). It also turns out that rounds 7-9 were run with a newer version of the bot. IIRC, they ran with HouseBot 0.7 r763 while the earlier rounds were run with HouseBot 0.7 r761. Ok, I have corrected this, thank you for telling me. Nick On Mon, Jun 16, 2008 at 12:33 PM, Nick Wedd [EMAIL PROTECTED] wrote: AyaMC and StoneGrid were the winners of yesterday's KGS bot tournament, both undefeated, with 6/6 and 9/9 wins respectively. My report is at http://www.weddslist.com/kgs/past/39/index.html It is longer than usual, because I found quite a few of the games interesting. Nick -- Nick Wedd[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/ -- Nick Wedd[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] Test position set for MC programs
On Problem 125, sounds like B2 is also a right move. On Wed, Apr 23, 2008 at 3:33 PM, Gunnar Farnebäck [EMAIL PROTECTED] wrote: Yamato wrote: Thanks Gian-Carlo, Gunnar. Current list of results. GNU Go 3.7.12 level 0 : 24/50 GNU Go 3.7.12 level 10 : 34/50 GNU Go 3.7.12 level 15 : 37/50 GNU Go 3.7.12 mc, 1k : 30/50 GNU Go 3.7.12 mc, 10k : 31/50 GNU Go 3.7.12 mc, 100k : 38/50 GNU Go 3.7.12 mc, light, 1k: 33/50 GNU Go 3.7.12 mc, light, 10k : 30/50 GNU Go 3.7.12 mc, light, 100k : 25/50 GNU Go 3.7.12 mc, mogo, 1k : 34/50 GNU Go 3.7.12 mc, mogo, 10k: 33/50 GNU Go 3.7.12 mc, mogo, 100k : 35/50 Leela 0.3.14, 1k : 19/50 Leela 0.3.14, 10k : 28/50 Leela 0.3.14, 100k : 36/50 Zen 1.5, 1k: 19/50 Zen 1.5, 10k : 22/50 Zen 1.5, 100k : 24/50 Leela seems to have good scalability. 36/50 passes is fine. The results of GNU Go are a bit irregular because of its hybrid strategy. If GNU Go could run on the MC only mode, it might be more interesting, I guess. Ok, I patched out the contributions from normal move generation in the final move selection (but there's still some influence on UCT tree move ordering), giving this list: Only MC GNU Go 3.7.12 level 0 : 24/50- GNU Go 3.7.12 level 10 : 34/50- GNU Go 3.7.12 level 15 : 37/50- GNU Go 3.7.12 mc, 1k : 30/50 14/50 GNU Go 3.7.12 mc, 10k : 31/50 29/50 GNU Go 3.7.12 mc, 100k : 38/50 35/50 GNU Go 3.7.12 mc, light, 1k: 33/507/50 GNU Go 3.7.12 mc, light, 10k : 30/50 14/50 GNU Go 3.7.12 mc, light, 100k : 25/50 22/50 GNU Go 3.7.12 mc, mogo, 1k : 34/50 14/50 GNU Go 3.7.12 mc, mogo, 10k: 33/50 21/50 GNU Go 3.7.12 mc, mogo, 100k : 35/50 34/50 /Gunnar ___ 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] Suicide question
A question on this topic. When we discuss about suicide, are we referring to the real suicide, or self-atari? I think in some discussions it is referring to the real suicide. In other discussions, seems to be referring to self-atarai. If we are talking about real suicide, I do not see any point to allow the real suicide in the play out. What would be the gain if we allow the real suicide in the play out. I think its only effect is to introduces more board repetition and more moves in the playout. In very very rare cases a real suicide move is beneficial. If we are talking about the self-atari, that's a more interesting topic. I find it is very hard to tune. A lot of games of my engine are lost due to completely insane self-atari moves in the early games. Even I have policy to disfavor the self-atari moves, those moves just keep surfacing out. On Jan 18, 2008 9:28 AM, Michael Williams [EMAIL PROTECTED] wrote: So it's possible to create a triple-ko repetition, take that move sequence and find a non-triple-ko situation that uses the exact same repeated move sequence? A van Kessel wrote: An alternative to matching board hashes is to test for repeated move sequences. No. repeated position != repeated sequence. Since one stone is added to the board with each move, a repetition can only exist between two moves if exactly that number of stones was captured inbetween (+- pass moves) So you only have to check the positions in the game-stack where exactly the same number of black,white stones is on the board HTH, AvK ___ 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/
[computer-go] A bug with cgos tcl script when the engine crashes
When the engine crashes, the tcl scripts sends the last move from the opponent, and the engine loses on Illegal move to occupied point. Not sure if anybody has reported this bug and latest script has fixed the issue. The following is part of the script log on game 251055. The full log of the game is also attached. 08:30:28C-E genmove w 08:30:31E-C = D2 08:30:31C-S D2 08:30:41S-C play b E1 188090 08:30:41C-E play b E1 08:30:41E-C = 08:30:41S-C genmove w 246388 08:30:41C-E time_left w 246 0 08:30:41E-C = 08:30:41C-E genmove w 08:30:42E-C 08:30:42C-S E1 08:30:42S-C gameover 2008-01-12 B+Illegal move to occupied point 08:30:42C-S ready 251055.log Description: Binary data ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] How to get more participation in 19x19 CGOS?
I do not have a 19x19 bot right now. But I found that fast engines have to wait for slow engines is kind of boring. For example, if a majority of engines finish the game within 5 minutes and only one or two engines will finish the games in 30 minutes. Then all the fast engines have to wait the slow engines finish the game. Maybe we should consider scheduling games for the available engines at every 10 minutes while still leave the time limits for each game at 30 minutes? On Jan 8, 2008 4:06 PM, David Fotland [EMAIL PROTECTED] wrote: Then 15 minutes should be good. We want the anchor to play at the same strength as before. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Alain Baeckeroot Sent: Tuesday, January 08, 2008 12:40 PM To: computer-go Subject: Re: [computer-go] How to get more participation in 19x19 CGOS? Le mardi 8 janvier 2008, Don Dailey a écrit: ... On 19x19 it might be 30 minutes per side like we have now, with 5 minute games for the fast time control.We would probably have to work it out so that program like gnugo would be able to handle the fast time control at their standard settings. At level 10, gnugo might need more than 10 min for some games (with lots of possible ataris or kos). At level 0 (with tons of really ugly moves, and only 2 stones weaker on kgs) 5 min should be ok. I think adding handicap to 19x19 is really a needed feature. Alain ___ 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] How to get more participation in 19x19 CGOS?
hmm, what about the following schedule 1. Every minute, the server set up pairs randomly between all the engines, including both busy ones and idle ones. 2. Start the games between only the pairs which both are currently idling. For a pair, if either side is currently in a game, then the match between the pair is discarded. It seems servers the purpose. On Jan 8, 2008 6:12 PM, Don Dailey [EMAIL PROTECTED] wrote: John Fan wrote: I think they are slightly different unless I misunderstood yours. I was thinking fixing the game time limit as now, 30 minutes per side. But has a more flexible schedule. Just schedule the games for available engines as the server normally would do as long as enough engines available and a certain time passed. The server does not have to distinguish fast engines and slow engines. And engines does not have to register itself as slow engines or fast engines. Should be easier for the server to handle. This approach was abandoned long ago. The older CGOS server did it exactly this way - it would schedule games every 30 seconds or so if players were available. It's actually an interesting problem, because as I discovered it's hard to get fair scheduling when this is done. Consider the most common case: 1. Everyone is playing at the moment. 2. A match completes. 3. Guess who is available? The same 2 players that just finished. There is a solution to this (never schedule the same pair twice in a row), but the rules to keep weird stuff from happening get more and more complicated.It's difficult for instance to prevent fast players from playing each other most of the time. What I wanted on CGOS (in rough order of priority) is this: 1. Each player gets a good variety of opponents. 2. Players should tend to play equal opponents (but not solely) 3. Players should stay as busy as possible. All 3 goals conflict with each other - which is why I went to scheduling in discreet rounds.This is one of those problems that seem trivial at first, but when you get into it you see that it's way more difficult than you imagined.No matter what problem you see, there is always a simple solution which ends up having side-effects and so on. There doesn't exist a superficial solution. I think it's all about which trade-offs you want to make. Because if you prioritize one of the 3 goals, you can get different trade-offs.If you prioritize goal 3, for instance, which is what you are suggesting, you sacrifice goal 1 and 2 significantly. On the old server I had rules to try to salvage this situation but as you might guess, you can't have your cake and eat it too!The rules tended to hurt the very problem I wanted to solve and so would require programs to wait more in order to find viable opponents. In the end, I decided it was better to schedule in discreet rounds. It avoids all of those cyclic conditions that we had before where certain players would rarely meet because of timing issues.Because of the imposed delays to try to make the server more balanced it turns out that scheduling in discreet rounds is not that bad a solution - it does not decrease the frequency of play as much as I had imagined. You see this same problem on real servers too. You want to play a particular opponent, but he is in a game. You can wait for him, but then you are not playing. You can play a game meanwhile, but when you are finished he is playing someone else. The cycle can keep you locked out for a very long time.On CGOS this kind of cycling sometimes made it difficult for strong players to play each other - they were too busy playing weaker opponents. - Don On Jan 8, 2008 5:18 PM, Don Dailey [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: John Fan wrote: I do not have a 19x19 bot right now. But I found that fast engines have to wait for slow engines is kind of boring. For example, if a majority of engines finish the game within 5 minutes and only one or two engines will finish the games in 30 minutes. Then all the fast engines have to wait the slow engines finish the game. Maybe we should consider scheduling games for the available engines at every 10 minutes while still leave the time limits for each game at 30 minutes? I think you missed my posts - that's exactly what is planned. Essentially, there are 2 schedules running concurrently - a slow one and a fast one.The fast round is like a heartbeat - it is scheduled one after another. If your bot is not playing in a slow game it can play in the next available fast game. It will not have to worry about missing the next slow round either - the server will always wait for the current fast round to complete before scheduling a slow round. In this way, your bot
Re: [computer-go] MC-UCT and tactical information
My program StoneGrid calculates unconditional life and death at every move, in the UCT Tree and in the random playout. I think it helps on its strength a little bit, especially in the end game. In the begining of the game, seems to be completely useless. It is slow. But it makes the random playout slightly shorter. The random playout is about 80 moves per game. I do not have a comparison if the unconditional life and death is disabled, since it is not easy to do in the current data structure. On Dec 13, 2007 3:20 PM, Jason House [EMAIL PROTECTED] wrote: On Dec 13, 2007 2:17 PM, [EMAIL PROTECTED] wrote: I'd like to start a more specific discussion about ways to combine tactical information with MC-UCT. Here's the scenario. It's the bot's turn and, prior to starting any playouts, it runs a tactical analyzer (for want of a better name) that labels each string as unconditionally alive, unconditionally dead, conditionally alive, uncertain, or too strong to bother testing. For each conditionally alive string, it finds the move(s) to kill/rescue it. Each possible move, has a critical score indicating the net number of stones whose life/death status would be changed for the better if the bot moved there. Moves with a non-zero critical score are critical moves. As worded, I don't know if I agree with that formalization of what information will be useful. It's in the right ballpark for the discussion, but will likely shift a bit with any final design. * Connectivity. I confess to having no clue, but wise people on this list doubtless will. Connectivity of stones and LD for stones are intimately tied together. If I'm alive, I don't need a connection. If I connect to another living group, I don't need to live. I've been tempted to insert forced responses into my random playouts to preserve connections, but I didn't get that far since I don't have a tactical analyzer. One day I will... * Collect information from all those local searches and somehow use it in the global search. This is my long term goal. Maybe n-grams... What's an n-gram? I think that there is a crossover point where, once the cpu time needed to do a decent tactical analysis at the root becomes a small fraction of the total available for a move, it becomes worthwhile to do so. My program/hardware isn't there yet, but it's just a matter of time. Don't forget that local tactical analysis can be reused many moves later if the local area has remained unaffected. In a multi-core system, it may become increasingly valuable to dedicate a core to tactical analysis. ___ 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] MC-UCT and tactical information
Yes, StoneGrid only uses Benson's algorithm. On Dec 13, 2007 4:30 PM, [EMAIL PROTECTED] wrote: That's a strong program, and interesting information. For clarity, I assume that you mean something like Benson's algorithm, while my intended meaning was alive assuming perfect play. Both are relevant, we just need to keep them sorted out. - Dave Hillis -Original Message- From: John Fan [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 13 Dec 2007 3:42 pm Subject: Re: [computer-go] MC-UCT and tactical information My program StoneGrid calculates unconditional life and death at every move, in the UCT Tree and in the random playout. I think it helps on its strength a little bit, especially in the end game. In the begining of the game, seems to be completely useless. It is slow. But it makes the random playout slightly shorter. The random playout is about 80 moves per game. I do not have a comparison if the unconditional life and death is disabled, since it is not easy to do in the current data structure. -- More new features than ever. Check out the new AIM(R) Mailhttp://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aimcmp000501 ! ___ 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] CGOS down? Java client - basic GTP problem
I guess the issue is on the id field. Id field is only optional. If the request has no id field, the response should not have it either. In your code example, it seems you always reply back with an id field. On Nov 27, 2007 1:40 PM, Harri Salakoski [EMAIL PROTECTED] wrote: command genmove w 30 reply=30 E3 cgos replys gameover 2007-11-27 B+Illegal do not understand syntax GTP specc says : Success Responses - A successful response has one of the syntaxes =id response\n\n =id\n\n = response\n\n =\n\n code is: return = + id + + s + \n\n; stream is written using PrintWriter: myToServer.println(line); Anybody used java with cgos could help or if it is otherway obivious. t.Harii 27.11.2007 20:30:14 narugo.util.MyLog log INFO: Server:gameover 2007-11-27 B+Illegal do not understand syntax - Original Message - From: Harri Salakoski [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Tuesday, November 27, 2007 6:32 PM Subject: [computer-go] CGOS down? Java client Hmm, I am not sure as only trying to make Java bot connect CGOS, but it seems to be down. It seems that it does not give feedback after password. Also I found cgos email list cgos-developers is it also for users or is this list ok? t. harri ___ 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] Chinese Computer Games Championship
The tables are the list of the programs, not the results. I read Ping Yu's blog. He is a professional go player. His program should have won both on 19x19 and 9x9. Here is the link of his blog, again it is in Chinese. http://blog.csdn.net/Yoenix/archive/2007/10/10/1817821.aspx According to his blog, Professor Chen's program should have won, but Professor Chen's program was participating not for the prize. On Nov 14, 2007 2:53 PM, Nick Wedd [EMAIL PROTECTED] wrote: I have now found what seems to be the results page of the Chinese Computer Games Championship, held in Chongqing in early October. It's at http://aigames.cn:8081/CCGCC/teamInfo.jsp It seems that Break won the 19x19 Go, and BitStronger won the 9x9. But there seem to be no scores listed, so it's possible that these aren't results tables. Nick -- Nick Wedd[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/
[computer-go] gtp command time_left difference between cgos and kgs
In the recent kgs tournament, I noticed there is a slight difference between cgos and kgs on time_left command.I think it worths pointing out. Hope it will be helpful for new go developers on understanding of the time control commands. cgos always sends time_left command right before genmove command. kgs always sends time_left command right after genmove command. In the tournament, StoneGrid assumed the cgos sequence, assuming the last time_left command was the accurate one, and simply ignored the time_settings command. Since I had tested StoneGrid primarily on the cgos, I assumed kgs will send the commands in the same sequence. The consequence of the oversight is when the previous game finished, and next game started, StoneGrid used the time_left command from last game, and rushed to generate the first move. It is not an issue if it plays black, since it plays the center point anyway. But if it plays white, it picks less optimal move. Obviously I need to fix my program to reset the time controls on the time_settings command, and should not always expect a time_left command after the time_settings command on the first move. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] gtp command time_left difference between cgos and kgs
My program only knows the absolute time control yet. I will keep that in mind when I add the full time control support. Thanks for the note. On Nov 13, 2007 1:59 PM, Jason House [EMAIL PROTECTED] wrote: On Nov 13, 2007 1:51 PM, John Fan [EMAIL PROTECTED] wrote: Obviously I need to fix my program to reset the time controls on the time_settings command, and should not always expect a time_left command after the time_settings command on the first move. Just a small word of warning - KGS's handling of the time_settings command did not match my expectations when I was using non-absolute time. CGOS and KGS will use kgs-time_settings if it's available. While it is a variable number of arguments, it's easier to interpret correctly. ___ 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/
