[computer-go] about the solution of Japanese Rule
Hi all, I heard that the UCE cup is set to use Japanese rule, which is quite different from Chinese rule when players play PASS. It is ok to play another pass after a pass, but it seems to be problem if two players all pass in the middle game. is there any better solution to this problem? Fan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] about the solution of Japanese Rule
I'm not sure what you are asking, but when you are playing with Japanese rules, don't pass in the middle game. The simple solution is to wait until the game is over and all dame are filled before you pass. From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of xiefan Sent: Saturday, October 31, 2009 5:40 AM To: computer-go@computer-go.org Subject: [computer-go] about the solution of Japanese Rule Hi all, I heard that the UCE cup is set to use Japanese rule, which is quite different from Chinese rule when players play PASS. It is ok to play another pass after a pass, but it seems to be problem if two players all pass in the middle game. is there any better solution to this problem? Fan ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] about the solution of Japanese Rule
xiefan wrote: Hi all, I heard that the UCE cup is set to use Japanese rule, which is quite different from Chinese rule when players play PASS. It is ok to play another pass after a pass, but it seems to be problem if two players all pass in the middle game. is there any better solution to this problem? Fan Hi, In the Computer Olympiad, in 2006, AjaGo was playing mirror Go, and when its opponent played on tengen, replied by a pass. Mango had a rule to pass after the opponent passes. So after Mango played tengen in the opening, both passed. That was a funny situation. Since the programs were too stubborn to play a move, the referee adjudicated the game as a draw. When I told Professor Muramatsu that Crazy Stone has a rule to pass as soon as the opponent passes in order to play with Japanese rules, he was a bit worried, and told me that I should make sure that it does not pass in the opening or the middle game. You should be ready to meet opponents that are very weak or buggy, and would play a pass in the opening. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Neural networks
Present day MC Go programs are neural networks. The playout is the trainng process. DL -Original Message- From: Petr Baudis pa...@ucw.cz To: computer-go@computer-go.org Sent: Wed, Oct 14, 2009 7:26 am Subject: [computer-go] Neural networks Hi! Is there some high-level reason hypothesised about why there are o successful programs using neural networks in Go? I'd also like to ask if someone has a research tip for some nteresting Go sub-problem that could make for a nice beginner neural etworks project. Thanks, -- Petr Pasky Baudis lot of people have my books on their bookshelves. hat's the problem, they need to read them. -- Don Knuth __ omputer-go mailing list omputer...@computer-go.org ttp://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] MPI vs Thread-safe
On Fri, Oct 30, 2009 at 12:50 PM, Brian Sheppard sheppar...@aol.com wrote: Parallelization *cannot* provide super-linear speed-up. I don't see that at all. This is standard computer science stuff, true of all parallel programs and not just Go players. No parallel program can be better than N times a serial version. The result follows from a simulation argument. Suppose that you had a parallel process that performed better than N times a serial program. Construct a new serial program that simulates the parallel process. There is a contradiction. Technically, this argument only establishes the fact up to multiplicative constant. But in the case of parallel Go players, I cannot accept that simulating a parallel process using serial code would result in a slowdown. (If anything, serialization would be faster.) At the risk of belaboring the obvious, extra memory associated with each processor or node (cache, main memory, hard disk, whatever) is one reason adding nodes can in practice give a speedup greater than the increase in processing power. It may not be a typical result, but it's not rare, either. It's like when you have two processes that hum along when each given their own machine, but when you try to run them both on the same machine, the system thrashes and runs ten times slower. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MPI vs Thread-safe
Parallelization *cannot* provide super-linear speed-up. ... The result follows from a simulation argument. Suppose that you had a parallel process that performed better than N times a serial program. Construct a new serial program that simulates the parallel process. There is a contradiction. ... The paper suggests the cause of the super-linear speed-up is that a thread gets caught in local optima (which it doesn't escape from within the designated thinking time). It also says if each thread was given more time then the speed-up factor may become less. It sounds like it is definitely worth exploring the parameters of root parallelization some more. At the risk of belaboring the obvious, extra memory associated with each processor or node (cache, main memory, hard disk, whatever) is one reason adding nodes can in practice give a speedup greater than the increase in processing power. That is an interesting idea. The paper says: experiments were performed on the supercomputer Hyugens, which has 120 nodes, each with 16 cores POWER5 running at 1.9Ghz and having 64Gb of memory per node. Experiments were done from 1 to 16 threads, but I cannot see mention in the paper whether 16 threads means one nodes using 16 cores, or 16 nodes using one core of each. Perhaps Guillaume can tell us. The experiment to decide if a hardware or algorithm cause of the super-linear speed-up is to try the single thread version by having it run 4 searches one after another, and merging results. I.e. if that gives a performance boost over one long search then the cause must be algorithmic? (?) Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/gobet/ (Shodan Go Bet - who will win?) http://dcook.org/mlsn/ (Multilingual open source semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MPI vs Thread-safe
Darren Cook: 4aecdf3e.7010...@dcook.org: Parallelization *cannot* provide super-linear speed-up. ... The result follows from a simulation argument. Suppose that you had a parallel process that performed better than N times a serial program. Construct a new serial program that simulates the parallel process. There is a contradiction. ... The paper suggests the cause of the super-linear speed-up is that a thread gets caught in local optima (which it doesn't escape from within the designated thinking time). It also says if each thread was given more time then the speed-up factor may become less. It sounds like it is definitely worth exploring the parameters of root parallelization some more. At the risk of belaboring the obvious, extra memory associated with each processor or node (cache, main memory, hard disk, whatever) is one reason adding nodes can in practice give a speedup greater than the increase in processing power. That is an interesting idea. The paper says: experiments were performed on the supercomputer Hyugens, which has 120 nodes, each with 16 cores POWER5 running at 1.9Ghz and having 64Gb of memory per node. Experiments were done from 1 to 16 threads, but I cannot see mention in the paper whether 16 threads means one nodes using 16 cores, or 16 nodes using one core of each. Perhaps Guillaume can tell us. In that paper, clearly Guillaume used only shared-memory parallel, not network. So the former must be collect. The experiment to decide if a hardware or algorithm cause of the super-linear speed-up is to try the single thread version by having it run 4 searches one after another, and merging results. I.e. if that gives a performance boost over one long search then the cause must be algorithmic? (?) The PRNG (pseudo random number generator) can cause the super-linear speed-up, for example. For deteministic computations Brian is correct but since MCTS is a stocastic process, there could be other possibilities... Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9).
Hideki, Thank you. Your results look quite compelling. Do you allow memory (the number of nodes in the tree) to grow along with thinking time or is there a fixed limit? IIRC Don et. al.'s excellent scaling studies included gnugo but its effect was probably small. Self play dominated. Perhaps, what David Doshay calls, the evil twin effect causes self play to give the appearance of scaling better. - Dave Hillis -Original Message- From: Hideki Kato hideki_ka...@ybb.ne.jp To: computer-go computer-go@computer-go.org Sent: Sat, Oct 31, 2009 10:39 pm Subject: Re: [computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9). hillism...@netscape.net: 8cc26e08cfc0f77-5fd0-a...@webmail-m052.sysops.aol.com: -Original Message- From: Hideki Kato hideki_ka...@ybb.ne.jp To: computer-go computer-go@computer-go.org Sent: Wed, Oct 28, 2009 1:41 am Subject: Re: [computer-go] First ever win of a computer against a pro 9P as lack (game of Go, 9x9). ... BTW, recently I've measured the strength (win rate) vs time for a move curves with Zen vs GNU Go and Zen vs Zen (self-play) on 19 x 19 board. Without opening book, it saturates between +400 and +500 Elo against GNU but doesn't upto +800 Elo in self-play. That's somewhat interesting (detail will be open soon at GPW-2009). Hideki I'd say that is more than somewhat interesting. While we're waiting for the aper, can you give us a picture of how many games against Gnugo went into this nalysis? Do you see this in 9x9? I've attatched two charts of current results for convinience. hart1 is against GNU Go and Chart2 is self-play. The numbers for the 1st curve HA8000 (AMD Opteron 2.3GHz) 16 thread n Chart1 are: ime(s) Win DrawAll Dup WR std-dev Elo .02325 27 2,933 0 11.54% 0.59% -353.8 .1 509 23 728 0 71.50% 1.67% +159.8 .2 946 47 1,147 0 84.52% 1.07% +294.9 .5 1,803 60 2,000 0 91.65% 0.62% +416.2 .0 1,849 33 2,000 0 93.28% 0.56% +456.8 .0 4,455 121 4,812 0 93.84% 0.35% +473.1 The numbers for Chart2 are: ime(s) Win DrawAll Dup WR std-dev Elo .1 147 4 2,000 0 7.45% 0.59% -437.7 .3 992 36 2,000 0 50.50% 1.12% +3.5 .0 3,742 38 4,000 0 94.03% 0.37% +478.8 .0 13,157 43 13,328 1 98.89% 0.09% +779.3 Since above results are measured with no opening book, I'm now enchmarking opening book enabled but right now the samples are ot enough (642 games; see the 4th curve in Chart1, HA8000 (AMD pteron 2.3GHz) 16 thread w/ Book). Not a curve but a point now :-) For 9x9 it's not clear. The curve starts saturating near +500 Elo ut still seems increasing. Hideki - g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ omputer-go mailing list omputer...@computer-go.org ttp://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] TAAI computer Go tournament in Taiwan
The tournament was held at October 30th at Chaoyang University of Technology in Taichung, Taiwan, with TAAI2009, the 14th Conference on Artificial Intelligence and Applications, http://taai2009.inf.cyut.edu.tw/ (in Chinese). Both 9x9 and 19x19 were played in one day with 5 round swiss. Each round has one game for 19x19 and two games alternating B and W for 9x9. See http://ai.csie.ndhu.edu.tw:9898/eng/ for detail. You can see the all attendants by clicking News in the left menu now. Although the results are not yet in above site, I'd like to report the double wins of Zen for both boards. For 9x9, Zen won all games including with MoGoTW. For 19x19, Zen lost one game with MoGoTW but unfortunately MoGoTW lost two games by time due to frequent crashes. After the final round there were three teams with four wins and Zen won by SD (same as SOS? I'm not sure). You can have all game records between Zen and MoGoTW at KGS with the name Zen19 and Zen9gg (or MoGoTW19 and MoGoTW9). Hideki -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9).
dhillism...@netscape.net: 8cc28baed6fbe16-3fc0-16...@webmail-d068.sysops.aol.com: Hideki, Thank you. Your results look quite compelling. Do you allow memory (the number of nodes in the tree) to grow along with thinking time or is there a fixed limit? Each node of HA8000 cluster has 32 GB RAM which I believed is enough for a game with those time settings, up to 2s for a move, with no pondering, on 19x19. I observed, however, GC eventually run. I guess that affects little but I'll check it in the future experiments. IIRC Don et. al.'s excellent scaling studies included gnugo but its effect was probably small. Self play dominated. Perhaps, what David Doshay calls, the evil twin effect causes self play to give the appearance of scaling better. I have the same thought now. Perhaps my experimental results support such recent claim by strong players that strongest programs such as Zen are not so strong against human. It seems, however, too early to conclude anyway. Hidek -Original Message- From: Hideki Kato hideki_ka...@ybb.ne.jp To: computer-go computer-go@computer-go.org Sent: Sat, Oct 31, 2009 10:39 pm Subject: Re: [computer-go] First ever win of a computer against a pro 9P as black (game of Go, 9x9). hillism...@netscape.net: 8cc26e08cfc0f77-5fd0-a...@webmail-m052.sysops.aol.com: -Original Message- From: Hideki Kato hideki_ka...@ybb.ne.jp To: computer-go computer-go@computer-go.org Sent: Wed, Oct 28, 2009 1:41 am Subject: Re: [computer-go] First ever win of a computer against a pro 9P as lack (game of Go, 9x9). ... BTW, recently I've measured the strength (win rate) vs time for a move curves with Zen vs GNU Go and Zen vs Zen (self-play) on 19 x 19 board. Without opening book, it saturates between +400 and +500 Elo against GNU but doesn't upto +800 Elo in self-play. That's somewhat interesting (detail will be open soon at GPW-2009). Hideki I'd say that is more than somewhat interesting. While we're waiting for the aper, can you give us a picture of how many games against Gnugo went into this nalysis? Do you see this in 9x9? I've attatched two charts of current results for convinience. hart1 is against GNU Go and Chart2 is self-play. The numbers for the 1st curve HA8000 (AMD Opteron 2.3GHz) 16 thread n Chart1 are: ime(s) Win DrawAll Dup WR std-dev Elo .02325 27 2,933 0 11.54% 0.59% -353.8 .1 509 23 728 0 71.50% 1.67% +159.8 .2 946 47 1,147 0 84.52% 1.07% +294.9 .5 1,803 60 2,000 0 91.65% 0.62% +416.2 .0 1,849 33 2,000 0 93.28% 0.56% +456.8 .0 4,455 121 4,812 0 93.84% 0.35% +473.1 The numbers for Chart2 are: ime(s) Win DrawAll Dup WR std-dev Elo .1 147 4 2,000 0 7.45% 0.59% -437.7 .3 992 36 2,000 0 50.50% 1.12% +3.5 .0 3,742 38 4,000 0 94.03% 0.37% +478.8 .0 13,157 43 13,328 1 98.89% 0.09% +779.3 Since above results are measured with no opening book, I'm now enchmarking opening book enabled but right now the samples are ot enough (642 games; see the 4th curve in Chart1, HA8000 (AMD pteron 2.3GHz) 16 thread w/ Book). Not a curve but a point now :-) For 9x9 it's not clear. The curve starts saturating near +500 Elo ut still seems increasing. Hideki - g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ omputer-go mailing list omputer...@computer-go.org ttp://www.computer-go.org/mailman/listinfo/computer-go/ inline file ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- g...@nue.ci.i.u-tokyo.ac.jp (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
