Re: [computer-go] winning a won game
On Thu, Dec 06, 2007 at 06:39:17PM -0500, Chris Fant wrote: I propose a far more powerful and correct set of rules: 1. Play the move that gives you the best chance of winning. That would be lovely - if we had a good way of estimating those chances. It is (should be) well known that MC playouts are not perfect. They seem to be good enough to use as an evaluation function in a tree search, but if you look at programs that uses only MC evaluation, you can see that they don't play very strong. There are some things MC just can not see. It only sees groups as unconditionally alive if they have two separate eyes, not if it has one large eye - no matter if that is clearly alive (say five points in a row). It sees a definite risk of getting cut through a bamboo joint. All this comes naturally from playing random moves, and not reacting to forcing moves that for us humans look all too obvious. Having said that, I am not trying to rake down MC techniques. In fact, I am writing my own MC-based program (although I am too short of time to see any real progress. Don't expect anything new on cgos the next few months!). I have some ideas I want to explore, maybe I am lucky and one of them turns out to be useful. - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Re: Update of MoGo binary release, and windows version available!
Hi, I have a solution now, thanks for all the help. For those interested, the solution for me: I use a ruby script (thanks Chris), to open de mogo program (with IO.popen) and with gets en puts it is possible to read the commands from stdin, and outputs these commands to mogo. Obvously ruby can send these commands without EOF, so mogo does work properly this way. I noticed however that is could be necessary to wait for the reply of mogo before sending another command, because otherwise it sometimes fails. Thanks, Edward. From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: [computer-go] Re: Update of MoGo binary release, and windows version available!Date: Wed, 5 Dec 2007 11:23:42 +0100 Hi to all, Can someone help me with this problem, for which I cannotfind a solution:I am trying to run MoGo in an automatic way, using thecygwin toolkit.The problem in its simplest form is this:If I use MoGo on the command line, typing the commands whichare send by stdin (i suppose) it works perfectly.If I make a file with command like: boardsize 9 genmove wThen MoGo will continue to perform a genmove, and can onlybe stopped by killing it.I vagely suspect that it has something to do with non-blockinginput, but I also do not know all the aspects of this.To be honest, I tried to implement pondering using non-blockinginput, but that did not work out this way, because of some alikeproblems... Now I can run GoGui, and this program seems to work finewith Mogo, so it must be possible to interact automatically. Can you help me?What am I doing wrong? Thanks,Edward Pas je zoekresultaten aan op JOUW wensen met Live.nl! Live.nl _ http://www.live.com/?mkt=nl-nl Live.nl___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Update of MoGo binary release, and windows version available!
No problem. You might also be able to use my Ruby GTP implementation: http://fantius.com/Gtp.html On Dec 7, 2007 5:49 AM, Edward de Grijs [EMAIL PROTECTED] wrote: Hi, I have a solution now, thanks for all the help. For those interested, the solution for me: I use a ruby script (thanks Chris), to open de mogo program (with IO.popen) and with gets en puts it is possible to read the commands from stdin, and outputs these commands to mogo. Obvously ruby can send these commands without EOF, so mogo does work properly this way. I noticed however that is could be necessary to wait for the reply of mogo before sending another command, because otherwise it sometimes fails. Thanks, Edward. From: [EMAIL PROTECTED] To: computer-go@computer-go.org Subject: RE: [computer-go] Re: Update of MoGo binary release, and windows version available! Date: Wed, 5 Dec 2007 11:23:42 +0100 Hi to all, Can someone help me with this problem, for which I cannot find a solution: I am trying to run MoGo in an automatic way, using the cygwin toolkit. The problem in its simplest form is this: If I use MoGo on the command line, typing the commands which are send by stdin (i suppose) it works perfectly. If I make a file with command like: boardsize 9 genmove w Then MoGo will continue to perform a genmove, and can only be stopped by killing it. I vagely suspect that it has something to do with non-blocking input, but I also do not know all the aspects of this. To be honest, I tried to implement pondering using non-blocking input, but that did not work out this way, because of some alike problems... Now I can run GoGui, and this program seems to work fine with Mogo, so it must be possible to interact automatically. Can you help me? What am I doing wrong? Thanks, Edward Pas je zoekresultaten aan op JOUW wensen met Live.nl! Live.nl Windows Live Messenger het beste van de toekomst Download NU! Windows Live Messenger! ___ 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] low-hanging fruit - yose
Aboute the Nakade problem: 1) There is in principle no problem to correctly handle nakade in MC/UCT programs. It just a question of making the playouts do it. 2) But doing this requires some smart programming. I think all the strong progams has been designed by the What can I do in less than 10 lines of code that improves playing strength and does not slow down the program-principle. The problems with Nakade is that it requires more effort than other stuff, so all energy has gone into for example playing urgent shapes and that has improved the engines immensely. 3) If one does efficiently implement Nakade it is not certain that the program will get stronger. My experience of adding LD knowledge is that if you mess up the balance between attack and defense you can get problems like: The program make invasions that does not work and defends aginst invasions that it could easily kill or It does not make territory because it wrongly thinks it can kill all invasions. This is really hard to handle. Basically you just see from tests that new code have a detrimental effect on playing strength, but there are no bad moves that can be debugged just a subtle switch in playing style that has a lower chance of winning. Valkyria partially handle life and death well. In playouts it will play the vital point right after a nakade capture for example. It has a remaining weakness in that it does not know what Nakade shapes gives one or two eyes, it only understands the empty space after a capture. In such cases the status of a group is evaluated as unstable although they may be unconditionally alive/dead. Before Mogo became invincible I noticed that Valkyria could often exploit LD weaknesses and steal the victory in otherwise lost games. But the price for having LD knowledge is that Valkyria is at least 10 times slower than for example Leela on the same hardware. Surprisingly to me LD tactics seems to be less important in computer go. What is really important is that the program knows how to attack and defend eyespace. If you win that fight 9 time out of 10 it does not matter that you lose 75% of the time in that single game where it was not settled early. Gnugo is good at LD, but I have seen Valkyria killing big groups on 13x13 ore larger simply because the MC programs can sniff out weaknesses in groups long before the static evaluation can. When these big groups die there is often no LD problem to solve there is just a lot of empty space that cannot be made into into two eyes. Humans need to practice LD a lot to get strong. But I see this as pushups to get muscle power. If you are not good at closed well defined problems you will also not be able to handle open ill-defined problems. And 95-99% of all moves in good game of go are in such positions. So, when human opponents complaines about Nakade it just means that the programmer has made the right design choices in what code the playouts need to make the program as strong as possible *given the programming effort*. This means that are a lot of potential to make the programs even stronger. But it may be really hard to find the right balance. You may want to add feature A and B but the program may only get stronger if you implement A and B simultaneously. A alone or B alone just makes the program weaker. I think the gnugo team wrote about similar experiences some time ago on this list. Quoting Darren Cook [EMAIL PROTECTED]: 2. Mogo (and CrazyStone) are using lots of intelligence in their playouts, and that is the cause of the nakade weakness. They are good players, but they have preconceptions. They consider the moves required to discover the difference between a nakade and dead-stones-in-a-definitely-alive-group as low priority. So, in that sense, they do have a concept of nakade. (I hope Remi, or one of the Mogo developers, will correct me if I've misunderstood what is going on.) -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GPUs and go algorithms?
You may wish to look at the CUDA docs: http://developer.nvidia.com/object/cuda.html#documentation and the Telsa GPU: http://www.nvidia.in/page/tesla_tech_specs.html Terry McIntyre [EMAIL PROTECTED] They mean to govern well; but they mean to govern. They promise to be kind masters; but they mean to be masters. -- Daniel Webster - Original Message From: Darren Cook [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, December 6, 2007 5:07:50 PM Subject: Re: [computer-go] GPUs and go algorithms? Joshua Shriver wrote: I've been looking into GPGPU for several years now, there was even some buzz in the comp-chess stream but the downsides seemed to be to much. Think the big problem is the latency on the PCI/AGP bus. Though that might not be as much an issue now with PCI-x, etc. Thanks. My question could've been rephrased as Can a basic alpha-beta searcher for chess be written to run on a GPU?. Can I take the above to mean Yes, but the overhead of calling it took too much time? Or were they putting some smaller part of the chess algorithm (e.g. leaf node evaluation or move sorting) on the GPU? (In which case I can see how communication overhead would drown out the performance gain.) For more info I'd refer you to this site which has been using GPU's for years. http://www.gpgpu.org/ Thanks, yes, that is a useful site. However I don't see anything related to tree search. Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
