Re: [spam probable] Re: [computer-go] Gnugo vs commercial programs
Hi Sylvain, On 1/10/07, Sylvain Gelly [EMAIL PROTECTED] wrote: So between the default level (8) and the level 16, there are 7% winning difference at around 50%, which is significant, but do not change by far the results Hiroshi posted. It is far less than 100 ELO right? I did not measure the thinking time of GnuGo level 16, but it seems quite long, and some games (at least 1, I don't remember) never finish after a lot of hours. Perhaps it is just a bug :). So I think using GnuGo level 8 is reliable (and for experiments much faster). If you have (or anyone else has) examples of .sgf-files with such extra-ordinary long thinking times for a single move, I would be interested in seeing them. (Send them to me, to gnugo-devel-at-gnu.org, or attach them at http://trac.gnugo.org/gnugo/ticket/160.) My suspicion is that most of them are related to explosion of branching factors in the local reading of ko fights - due to various reasons these are not very well controlled in GNU Go. Arend ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Hello Arend, Unfortunately I don't have the log files anymore. I just remember that it (at least one) was a position with a lot of stones (not a starting position). Sylvain 2007/1/20, Arend Bayer [EMAIL PROTECTED]: Hi Sylvain, On 1/10/07, Sylvain Gelly [EMAIL PROTECTED] wrote: So between the default level (8) and the level 16, there are 7% winning difference at around 50%, which is significant, but do not change by far the results Hiroshi posted. It is far less than 100 ELO right? I did not measure the thinking time of GnuGo level 16, but it seems quite long, and some games (at least 1, I don't remember) never finish after a lot of hours. Perhaps it is just a bug :). So I think using GnuGo level 8 is reliable (and for experiments much faster). If you have (or anyone else has) examples of .sgf-files with such extra-ordinary long thinking times for a single move, I would be interested in seeing them. (Send them to me, to gnugo-devel-at-gnu.org, or attach them at http://trac.gnugo.org/gnugo/ticket/160.) My suspicion is that most of them are related to explosion of branching factors in the local reading of ko fights - due to various reasons these are not very well controlled in GNU Go. Arend ___ 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: [spam probable] Re: [computer-go] Gnugo vs commercial programs
I have such games. It was with a expermental version of Suzie, were Suzie played quite aggressive/over optimistic. Gnu-Go calculated very long, but won these games at the end completly When Suzie plays sound and wins or looses only be a small margin, Gnu-Go plays also with level 16 relative fast. I am currently in my private house in Austria, the games are on my computer in Germany (where I work currently during the week). I will send it on Monday. Chrilly - Original Message - From: Arend Bayer To: computer-go Sent: Saturday, January 20, 2007 11:09 PM Subject: Re: [spam probable] Re: [computer-go] Gnugo vs commercial programs Hi Sylvain, On 1/10/07, Sylvain Gelly [EMAIL PROTECTED] wrote: So between the default level (8) and the level 16, there are 7% winning difference at around 50%, which is significant, but do not change by far the results Hiroshi posted. It is far less than 100 ELO right? I did not measure the thinking time of GnuGo level 16, but it seems quite long, and some games (at least 1, I don't remember) never finish after a lot of hours. Perhaps it is just a bug :). So I think using GnuGo level 8 is reliable (and for experiments much faster). If you have (or anyone else has) examples of .sgf-files with such extra-ordinary long thinking times for a single move, I would be interested in seeing them. (Send them to me, to gnugo-devel-at-gnu.org, or attach them at http://trac.gnugo.org/gnugo/ticket/160.) My suspicion is that most of them are related to explosion of branching factors in the local reading of ko fights - due to various reasons these are not very well controlled in GNU Go. Arend -- ___ 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] Gnugo vs commercial programs
2007/1/11, Don Dailey [EMAIL PROTECTED]: 50 X speedup sound rather impressive but it's not that much. It's probably made go programs about 2 or 3 stones stronger over the few years that it took to get hardward 50X faster about what you would expect. But it is hardly that much. Current programs are hardly 2-3 stones stronger ythat those in erly nineties. And if you comapare back them I used Goliath on my 286 20 MHz computer and today I use GnuGo on my 2GHz Athlon. So in bit over decade decade computers got about 100 times faster maybe 2-3 times more effetc/cycle so almost 300 times faster. And gain in strength is about 2-3 stones. So 50 times faster is lot faster. It will take more than few years to come. It may not help that much. Obviously any speed gain will help MC type program but I doubt not too much. MC probably will not dominate computer go in next decade. I am pretty sure we need some new ideas still to make progress. And By Go I mean a game that is played on 19x19 board. I find playing on 9x9 boring and not really a same game. Petri Pitkänen -- Petri Pitkänen e-mail: [EMAIL PROTECTED] Phone: +358 50 486 0292 ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
I still don't understand your point. Are you just trying to say computers have a long way to go to beat really strong humans? nope -- i'm saying that until extra time makes a measurable difference in the strength of a program, worrying about how much time a program spends on any particular activity (like winning or losing a game) is less important than worrying about the activity itself. s. Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 09:30 +0100, Sylvain Gelly wrote: So GnuGo and commercial programs have been optimized to play strong in very few time. For them, long thinking time is simply not relevant. It is not the same goal. Hi Sylvain, What I'm saying is that the programmers don't realize their real goal is to make it play better with less time. They THINK their goal is to make it play pretty good in about 10 seconds or whatever their goal is. But the 2 things are conceptually the same due to Moores law. You know this is true because just take a commercial program written 10 years ago. It makes it's moves quickly playing on an ancient piece of hardware with hardly any memory. So those guys kept expanding their program to use more time. It's only semantics whether you say they were trying to make it play better faster, or better in the same amount of time. But they stumbled around a lot because they were not thinking in a scientifically logical way. They only thought in absolute terms - I have 10 seconds per move, what can I do?Obviously, they wanted to play as strong as they could in those 10 seconds. The goal of scalability is the same thing that has always been done, it's just a more intelligent and methodical way to think about the problem. What makes me laugh is that some programmers imagine it has never been about time - just strength as though it is a totally unrelated concept. You scalability experiments with Mogo shows what should be painfully obvious - it's all about what you can do in a given amount of time and it should be no surprise that you can do more with more time. I agree that Gnugo was written in an absolute non-scalable style. Why Gnugo does is continually upgrade from year to year.They are making their program scale in a painfully manual way. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 04:18 -0800, steve uurtamo wrote: I still don't understand your point. Are you just trying to say computers have a long way to go to beat really strong humans? nope -- i'm saying that until extra time makes a measurable difference in the strength of a program, worrying about how much time a program spends on any particular activity (like winning or losing a game) is less important than worrying about the activity itself. Well then the time is now. Look at the Sylvain's post on the scalability of Mogo. - Don s. Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Well then the time is now. Look at the Sylvain's post on the scalability of Mogo. if the improvement continues to hold with more doublings, that's great. i am perhaps under the misguided opinion that there are all kinds of structural reasons why the best 'scalable' programs can't arbitrarily be doubled (i.e. that memory and not time was a bottleneck). s. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs - scalability
Since we can no longer count on doubling single-processor speed every 18 months, go programs will need to scale across multiple processors. Dual-core systems are common; a pair of duos can be had for $5K or so. IBM sells four dual-core processors in a single rackmount chassis, and can be expected to make four quad-cores available by the end of the year. Both Intel and AMD have announced multicore roadmaps. Less well-known processors, such as Sun's UltraSparc T1, have 8 cores and up to 32 simultaneous threads. Terry McIntyre - Original Message From: steve uurtamo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: computer-go computer-go@computer-go.org Sent: Thursday, January 11, 2007 4:18:01 AM Subject: Re: [computer-go] Gnugo vs commercial programs I still don't understand your point. Are you just trying to say computers have a long way to go to beat really strong humans? nope -- i'm saying that until extra time makes a measurable difference in the strength of a program, worrying about how much time a program spends on any particular activity (like winning or losing a game) is less important than worrying about the activity itself. s. Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 07:40 -0500, Don Dailey wrote: Of course there is some questions about how long Moore's law will hold. If you are referring to CPU speed doubling (as opposed to transistor count), then that has been over for at least 5 years. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software http://www.gotw.ca/publications/concurrency-ddj.htm The problem is that concurrency doesn't scale well. -Jeff ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
I am currently working with different pruning methods for 19x19 go. What worked for Valkyria on 9x9 become much to slow on 19x19 where full board evaluation of several 100 moves simply does not work. During christmas I was able to prune the number of candiate moves to perhaps a factor 4-20 depending on the stage of the game. It now starts to play much better with a minute per move, but I did an experiment where I let have 10 minutes per move (it took several days to play that game) and for some moves I let it think for an hour. It was 9 handicap game and when it resigned it was only losing with 4.5 points. One game does not prove anything, but it showed that my MC implementation has the potential as long as it become more efficient. That is by better move pruning methods and faster hardware. And improvements to the main algorithms of the progam should of course also make a difference. I have said this before but I repeat my point here that is that MC programs cannot just be moved from 9x9 to 19x19 right away. It will take a lot of new ideas, but eventually I think really strong programs are possible even on present hardware, and these programs will of course scale very wll on 19x19. It is my impression that scalability might even be better on 19x19 than for 9x9. Quoting Sylvain Gelly [EMAIL PROTECTED]: 2007/1/11, steve uurtamo [EMAIL PROTECTED]: Well then the time is now. Look at the Sylvain's post on the scalability of Mogo. if the improvement continues to hold with more doublings, that's great. I did not do further experiments as 35k simulations per move already takes 30s per move, so about 1h15min per game. As I never consider making less than 200 or 400 or even 800 games to have precise statistics, you can imagine the amount of computer time it asks. I have precise statistics only with 35k and 70k, and unprecises with 2 minutes per move. Yet, for scalability issues I could consider making much less games. If my lab's cluster becomes available again, I will certainly try and post the results. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs - scalability
On Thu, 2007-01-11 at 05:25 -0800, terry mcintyre wrote: Since we can no longer count on doubling single-processor speed every 18 months, go programs will need to scale across multiple processors. Dual-core systems are common; a pair of duos can be had for $5K or so. IBM sells four dual-core processors in a single rackmount chassis, and can be expected to make four quad-cores available by the end of the year. Both Intel and AMD have announced multicore roadmaps. Less well-known processors, such as Sun's UltraSparc T1, have 8 cores and up to 32 simultaneous threads. It will be interesting to see what happens. They have predicted this fall-off every year but it hasn't happened yet - invariably it will unless someone can exploit the laws of physics in a way we don't understand yet. I suspect we can still get many more doublings even on a single core - but it may involve significantly different technologies than silicon. - Don Terry McIntyre - Original Message From: steve uurtamo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: computer-go computer-go@computer-go.org Sent: Thursday, January 11, 2007 4:18:01 AM Subject: Re: [computer-go] Gnugo vs commercial programs I still don't understand your point. Are you just trying to say computers have a long way to go to beat really strong humans? nope -- i'm saying that until extra time makes a measurable difference in the strength of a program, worrying about how much time a program spends on any particular activity (like winning or losing a game) is less important than worrying about the activity itself. s. Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ __ Access over 1 million songs - Yahoo! Music Unlimited. ___ 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] Gnugo vs commercial programs
On Thu, 2007-01-11 at 07:52 -0500, Don Dailey wrote: I agree that Gnugo was written in an absolute non-scalable style. What Gnugo does is continually upgrade from year to year.They are making their program scale in a painfully manual way. I want to clarify what I said about Gnugo. I'm not being critical of this style - it's perfectly feasible to just upgrade often and keep up in this way. For instance if level 16 is now considered fairly optimal but just too slow, it might become the default level in a future release of gnugo in just a year or two - perhaps with algorithmic optimizations to speed this up further. But that's my point - by then and along with other improvements someone might say level 24 is best - and no doubt there would be other improvements to go along with this that makes it do more work. One could imagine a very clever engineer taking Gnugo 3.7.10 at level 16 and finding a way to make it run at 10 seconds per move.Whether this is possible or not - you get the point - it all comes down to making it do more in a given amount of time. Scalability is either explicit or implicit. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Hello Magnus, I am glad to hear your experiment in 19x19. Your pruning is based on expert go knowledge or another statistic? Do have some statistics of the level of your pruning method against another program (let's say gnugo :)) in 19x19? Sylvain 2007/1/11, Magnus Persson [EMAIL PROTECTED]: I am currently working with different pruning methods for 19x19 go. What worked for Valkyria on 9x9 become much to slow on 19x19 where full board evaluation of several 100 moves simply does not work. During christmas I was able to prune the number of candiate moves to perhaps a factor 4-20 depending on the stage of the game. It now starts to play much better with a minute per move, but I did an experiment where I let have 10 minutes per move (it took several days to play that game) and for some moves I let it think for an hour. It was 9 handicap game and when it resigned it was only losing with 4.5 points. One game does not prove anything, but it showed that my MC implementation has the potential as long as it become more efficient. That is by better move pruning methods and faster hardware. And improvements to the main algorithms of the progam should of course also make a difference. I have said this before but I repeat my point here that is that MC programs cannot just be moved from 9x9 to 19x19 right away. It will take a lot of new ideas, but eventually I think really strong programs are possible even on present hardware, and these programs will of course scale very wll on 19x19. It is my impression that scalability might even be better on 19x19 than for 9x9. Quoting Sylvain Gelly [EMAIL PROTECTED]: 2007/1/11, steve uurtamo [EMAIL PROTECTED]: Well then the time is now. Look at the Sylvain's post on the scalability of Mogo. if the improvement continues to hold with more doublings, that's great. I did not do further experiments as 35k simulations per move already takes 30s per move, so about 1h15min per game. As I never consider making less than 200 or 400 or even 800 games to have precise statistics, you can imagine the amount of computer time it asks. I have precise statistics only with 35k and 70k, and unprecises with 2 minutes per move. Yet, for scalability issues I could consider making much less games. If my lab's cluster becomes available again, I will certainly try and post the results. ___ 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] Gnugo vs commercial programs
- Original Message - From: Jeff Nowakowski [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, January 11, 2007 3:37 PM Subject: Re: [computer-go] Gnugo vs commercial programs On Thu, 2007-01-11 at 07:40 -0500, Don Dailey wrote: Of course there is some questions about how long Moore's law will hold. If you are referring to CPU speed doubling (as opposed to transistor count), then that has been over for at least 5 years. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software http://www.gotw.ca/publications/concurrency-ddj.htm The problem is that concurrency doesn't scale well. -Jeff Yes, the INTEL engineers have long solved the problems of the programmers. But now the programmers have to solve the problems of the engineers. They do not know what to do with additional gates. The simplest way is to add another core. And if you have still too much gates left, make a quad core. The problem is that concurrency doesn't scale well. I think it depends on the application. In the simplest case, a server with many processes, it scales well. There are other applications like graphics were scaling is up to a certain limit relative straightforward. And there are still other applications like Alpha-Beta search which scale badly. Although up to 4 processors even Alpha-Beta scales well. In the Hydra FPGA there are also enough gates for a 2nd chess-core. But until now I have not succeeded to get a speedup with the second core. One very nasty limiting factor is the slow PCI bus. The Software side can not feed this cores fast enough (the CPU speed is sufficient, but bringing it over the bus is the problem). Another problem is Alpha-Beta itself. The FPGAs search with a fixed depth 4. If at Depth 4 nothing is to distribute, because the first move creates already a cutoff, the second core sits idle. The bus problem is a general one. E.g. modern graphic cards have a very powerfull GPU. One could use this e.g. for the computation of neural networks. The theoretic speedup is impressive, but the practical is low or it even slows down things. The neural-network-computation must - in comparision to the data - very large. Otherwise the transfer of data eats up all the speedup. Chrilly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Hi Magnus, I don't understand who the players were in the 9 handicap game. Who received the handicap and who was Valkyria's opponent? Was the opponent the un-pruned version of Valkyria? more comments below ... On Thu, 2007-01-11 at 15:38 +0100, Magnus Persson wrote: I am currently working with different pruning methods for 19x19 go. What worked for Valkyria on 9x9 become much to slow on 19x19 where full board evaluation of several 100 moves simply does not work. During christmas I was able to prune the number of candiate moves to perhaps a factor 4-20 depending on the stage of the game. It now starts to play much better with a minute per move, but I did an experiment where I let have 10 minutes per move (it took several days to play that game) and for some moves I let it think for an hour. It was 9 handicap game and when it resigned it was only losing with 4.5 points. One game does not prove anything, but it showed that my MC implementation has the potential as long as it become more efficient. That is by better move pruning methods and faster hardware. And improvements to the main algorithms of the progam should of course also make a difference. I have said this before but I repeat my point here that is that MC programs cannot just be moved from 9x9 to 19x19 right away. It will take a lot of new ideas, but eventually I think really strong programs are possible even on present hardware, and these programs will of course scale very wll on 19x19. It is my impression that scalability might even be better on 19x19 than for 9x9. This is clearly true - but probably because the games are much longer. With some 19x19 experiments I did using my old-fashioned MC program (which has limited scaling) the improvements were enormous with a doubling of the number of play-outs. With 9x9 the improvements were also significant, but not nearly so much. - Don Quoting Sylvain Gelly [EMAIL PROTECTED]: 2007/1/11, steve uurtamo [EMAIL PROTECTED]: Well then the time is now. Look at the Sylvain's post on the scalability of Mogo. if the improvement continues to hold with more doublings, that's great. I did not do further experiments as 35k simulations per move already takes 30s per move, so about 1h15min per game. As I never consider making less than 200 or 400 or even 800 games to have precise statistics, you can imagine the amount of computer time it asks. I have precise statistics only with 35k and 70k, and unprecises with 2 minutes per move. Yet, for scalability issues I could consider making much less games. If my lab's cluster becomes available again, I will certainly try and post the results. ___ 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] Gnugo vs commercial programs
The bus problem is a general one. E.g. modern graphic cards have a very powerfull GPU. One could use this e.g. for the computation of neural networks. The theoretic speedup is impressive, but the practical is low or it even slows down things. The neural-network-computation must - in comparision to the data - very large. Otherwise the transfer of data eats up all the speedup. this reminds me of two 'graduate student' hacks i got to see in the early 90's. the SGI machines at that time had special-purpose hardware to do point rotations and translations, and a giant bank of high-speed RAM that would otherwise go unused if you weren't doing graphics. the thinking was, hey, why not break down this NxN matrix multiplications into little 4x4 pieces, and use the graphics ram as if it were freely available for any particular purpose. feed the data array in as if it were a group of points describing an object that you needed to rotate, hit it against the 4x4 chip with parameters representing little 4x4 chunks of the larger NxN transformation, and read your data out of the graphics RAM as it became available. another cute trick that i still laugh about was a solution to the 'there are no machines available for you to use' problem. the affected student rewrote his code in postscript and sent it to the printer. sure, it tied up the cheap processor in the printer overnight, but then it printed out the results. :) s. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
But often it also suddenly pick a really bad move and play it so the descrioption above is a little idealized. Did you try picking the move with the highest number of simulations rather than the higher average? This only modification gave MoGo a +10% against gnugo in 19x19 (from 40% to 50% with 70k sim/move). And you can't say that it is a difficult modification to do :). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 17:13 +0100, Magnus Persson wrote: When I watch Valkyria analyze a 19x19 position it often goees like this: For the first 30 seconds or so it almost random, it does not have the statistical power to pick out good moves. Then it starts jump around between some moves that at least make sense. After 2-10 minutes it might actually pick out one or more really good moves which one would expect a 10 kyu player to play. But often it also suddenly pick a really bad move and play it so the descrioption above is a little idealized. Some critical move it actually finds after a few seconds so I really have to use some more flexible time control. Yes, it's fun watching this process. Here is how I think of Mogo and Gnugo by analogy: I use to know a expert level chess player and I considered him non-scalable. He loved speed-chess, always made his decisions very quickly and they were usually pretty good ones.He had no use for extra time because he knew right away what move he wanted to play. In tournaments I would be still in the opening and see him walking around - his game was already over and he would have a big grin on his face whether he won or lost. He laughed about it no matter what happened. Gnugo reminds me of this. It plays a pretty good move very quickly and to a certain extent it's decision is not reversible. But your description of Mogo shows the opposite approach. Mogo NEVER knows for sure what to play and like to keep refining it's decision making process. It starts out rather ignorant and indecisive, but always remains objective, willing to admit it was wrong and that some other move might possibly be better. Give it more time and it is happy to continue checking if it can improve. A very humble and thorough approach. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Magnus, I applied my analogy to Mogo, but I really meant any good UCT program such as yours - I just forgot who I was responding to in my last email. - Don On Thu, 2007-01-11 at 17:13 +0100, Magnus Persson wrote: Quoting Don Dailey [EMAIL PROTECTED]: I don't understand who the players were in the 9 handicap game. Who received the handicap and who was Valkyria's opponent? Was the opponent the un-pruned version of Valkyria? No, the opponent was myself, european 2 Dan as white taking a 9 handicap on 19x19. If a program can give me trouble with 9 stones then I consider it as strong for a program. I might also be playing a little nice when I test my programs, since I want to see how it reacts to proper moves not to really aggressive tricky ones. more comments below ... This is clearly true - but probably because the games are much longer. With some 19x19 experiments I did using my old-fashioned MC program (which has limited scaling) the improvements were enormous with a doubling of the number of play-outs. With 9x9 the improvements were also significant, but not nearly so much. When I watch Valkyria analyze a 19x19 position it often goees like this: For the first 30 seconds or so it almost random, it does not have the statistical power to pick out good moves. Then it starts jump around between some moves that at least make sense. After 2-10 minutes it might actually pick out one or more really good moves which one would expect a 10 kyu player to play. But often it also suddenly pick a really bad move and play it so the descrioption above is a little idealized. Some critical move it actually finds after a few seconds so I really have to use some more flexible time control. ___ 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] Gnugo vs commercial programs
Quoting Sylvain Gelly [EMAIL PROTECTED]: Hello Magnus, I am glad to hear your experiment in 19x19. Your pruning is based on expert go knowledge or another statistic? Do have some statistics of the level of your pruning method against another program (let's say gnugo :)) in 19x19? There are several ways it prunes. The Valkyria code itself refuses to play some really bad moves in the simulations such as destroying its own eyeshape. These moves are also pruned at the root. In the opening a lot of moves can be pruned by pattern matching and these I can make by hand (go knowledge - but not really at expert level). Finally I use a pruning method I have been using with non-MC programs where moves evaluated bad at ply n is pruned when they are evaluate again at ply n + 2 and their local neighborhood has not been changed. This method is a little crude and perhaps a little risky, but the gains clearly outweighs the disadvantages. I have not made any test yet, since it is all in development. None of the methods above changes the UCT-search itself. It is just some crude means to generate fewer moves. But I have been thinking about the UCT-search and think it has a problem that maybe some mathematical guy like you can fix in sound way. The thing is that on 19x19 there can be several 100 candidate moves. Given inifinite time the search will find the best move. But when it is very little time *left* to search I think it is a waste of time to spend effort on the moves that are the worst since they seem very unlikely to become the best move before we run out of time (at some point in time it is even impossible). I think the ideal algorithm should be sensitive to the time left and start to prune moves accordingly. UCT already does this to some extent, but I believe it does so only with very long thinking times. The only idea I had in this direction is that is probably never bad to prune the worst candidate in every position after some effort has been made. But how many moves with bad evaluations canbe pruned and under what conditions? -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Thu, 2007-01-11 at 17:19 +0100, Sylvain Gelly wrote: But often it also suddenly pick a really bad move and play it so the descrioption above is a little idealized. Did you try picking the move with the highest number of simulations rather than the higher average? This only modification gave MoGo a +10% against gnugo in 19x19 (from 40% to 50% with 70k sim/move). And you can't say that it is a difficult modification to do :). This is an important improvement and I discovered it myself long ago. Another way is to go into overtime if the best move isn't the most simulated move. It's not clear to me whether you should go to this extra trouble and my current program does the simple thing - exactly as you describe it, just play the most simulated move. I used to extent the thinking time until both the best and most simulated matched - but you have to put some kind of cap on it.I'm really not sure it helps over simply choosing the most simulated move. In problem testing, you will see that when the right move becomes the BEST move, it still takes a few moments before it becomes the most simulated move, but it happens relatively quickly. - Don Sylvain ___ 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] Gnugo vs commercial programs
Quoting Sylvain Gelly [EMAIL PROTECTED]: But often it also suddenly pick a really bad move and play it so the descrioption above is a little idealized. Did you try picking the move with the highest number of simulations rather than the higher average? This only modification gave MoGo a +10% against gnugo in 19x19 (from 40% to 50% with 70k sim/move). And you can't say that it is a difficult modification to do :). No I have not tried that yet. I think I have been planning to modify time control, so that it will try to stop thinking when the highest winrate has been searched significantly more than the second highest winrate. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Did you try picking the move with the highest number of simulations rather than the higher average? This only modification gave MoGo a +10% against gnugo in 19x19 (from 40% to 50% with 70k sim/move). And you can't say that it is a difficult modification to do :). This is an important improvement and I discovered it myself long ago. Yes I remember, and we already discused that on this list. However the improvement on 9x9 was very small whereas it is huge in 19x19. It is why I recall this. Another way is to go into overtime if the best move isn't the most simulated move. Yes; It's not clear to me whether you should go to this extra trouble and my current program does the simple thing - exactly as you describe it, just play the most simulated move. I used to extent the thinking time until both the best and most simulated matched - but you have to put some kind of cap on it.I'm really not sure it helps over simply choosing the most simulated move. I am pretty sure that intelligent time control in 19x19 would be great. But it is not so obvious, and a lot of test has to be done (I never did any). Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
No I have not tried that yet. I think I have been planning to modify time control, so that it will try to stop thinking when the highest winrate has been searched significantly more than the second highest winrate. Perhaps a more elaborate time control should be useful. Maybe it is better to consider also the speed of change. A quick change would mean that something is not stable about the position, so you have to think more. I would be happy to hear about precise experiments. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Finally I use a pruning method I have been using with non-MC programs where moves evaluated bad at ply n is pruned when they are evaluate again at ply n + 2 and their local neighborhood has not been changed. This method is a little crude and perhaps a little risky, but the gains clearly outweighs the disadvantages. I tried something similar while not totally pruning the move. Simply takes the statistics of one parent to initialize the UCT statistics. It was of little help in 9x9. I did not try in 19x19. But when it is very little time *left* to search I think it is a waste of time to spend effort on the moves that are the worst since they seem very unlikely to become the best move before we run out of time (at some point in time it is even impossible). I think the ideal algorithm should be sensitive to the time left and start to prune moves accordingly. UCT already does this to some extent, but I believe it does so only with very long thinking times. I think it should be easy, given a UCT tree and the time left, to compute if one move has a chance to become best before the end or not. However, I think it should be more usefull to build an adaptative time control, rather than trying to improve UCT with hard time control. Sylvain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
Chrilly, The computer go guys don't think of performance as a function of time, only as a kind of absolute, it plays good or it doesn't. Us computer chess people are used to thinking of it as a function of how fast the computer is and how much memory (along with how well the code is written of course.) The UCT programs, assuming they are properly coded and bug free, all play perfectly, but what really counts is how well they play given some time constraint. Again, most of the computer GO people do not think in those terms. It's very encouraging to me that Hiroshi reported the thinking times, I think he understands that it is relevant. - Don On Wed, 2007-01-10 at 21:01 +0100, Chrilly wrote: You must test with Gnu-Go level 16.. This is according to Stefan Mertin by far the best mode. But it takes sometimes quite a long time till Gnu-Go makes it move. In your experiments Gun-Go played very fast. You played fast Blitz and Gnu-Go had a big time handicap (besides Handtalk, which plays Ultra-Blitz). Chrilly - Original Message - From: Hiroshi Yamashita [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 10, 2007 6:10 PM Subject: [computer-go] Gnugo vs commercial programs I tested Gnugo against some commercial programs. Gnugo is 3.7.10. Level is default with --never-resign and --komi 6.5 option. Commercial program is max level. All game is Japanese rule and komi is 6.5. gnugo wins losses winning rate average score GinseiIgo5 (KCC Igo ) 1155 0.17 -31.3 points Saikouhou3 (Haruka ) 1344 0.23 -41.4 points TuyoiIgo4 (Go4++ ) 2754 0.33 -11.4 points ShudanTaikyoku3 (Handtalk) 2937 0.44 - 4.5 points GinseiIgo5 ... KCC Igo, published in 2004. Saikouhou3 ... Haruka, published in 2002. Latest version. TuyoiIgo4 ... Go4++,published in 2003. Engine is 2002 version. ShudanTaikyoku3 ... Handtalk, published in 1999. These are not latest version except Haruka. All game records are here. http://www.yss-aya.com/gnugo_vs_result.zip Average expended hours. KCC 17m51s Gnugo 3m14s, Opteron248(2.2GHz) Haruka 11m53s Gnugo 4m28s, Opteron248(2.2GHz) + AthlonXP 2100+(1.73GHz) Go4++ 4m59s Gnugo 2m18s, Opteron248(2.2GHz) Handtalk 2m42s Gnugo 5m22s, AthlonXP 2100+(1.73GHz) Appendix. GnuGo 3.5.4 (January, 2004 version) test result. Level is default. gnugo wins losses winning rate average score ValueIgo3 (KCC Igo ) 426 0.13 -36.6 points TuyoiIgo4 (Go4++) 1119 0.37 -6.5 points ShudanTaikyoku3 (Handtalk ) 1218 0.40 -3.8 points AI Igo2004 (ManyFaces) 1812 0.60 +11.7 points ValueIgo3 ... KCC Igo, published in 2003. same GinseiIgo2PW(2001?) AI Igo2004 ... ManyFaces, published in 2003. engine is 2003? --- Regards, Hiroshi Yamashita ___ 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] Gnugo vs commercial programs
in absolute terms, the time issue doesn't matter until some piece of code is good enough to beat a dan-level player on a 19x19 board at *any* physically realistic time constraint. which hasn't yet been demonstrated. the super slow motion tournament would be a good way for us to notice when this happens. (i.e when program X can give program Y 9 stones when program Y has a 30 minute time limit and program X has a 24 hour time limit, and they're normally much closer in strength when they both play at 30 minute time limits). as an example, if any program could give gnugo 9 stones under these circumstances, it might be good evidence that we're within a factor of 50x in speed of being capable of beating a 1d player. s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 10, 2007 7:24:38 PM Subject: Re: [computer-go] Gnugo vs commercial programs Chrilly, The computer go guys don't think of performance as a function of time, only as a kind of absolute, it plays good or it doesn't. Us computer chess people are used to thinking of it as a function of how fast the computer is and how much memory (along with how well the code is written of course.) The UCT programs, assuming they are properly coded and bug free, all play perfectly, but what really counts is how well they play given some time constraint. Again, most of the computer GO people do not think in those terms. It's very encouraging to me that Hiroshi reported the thinking times, I think he understands that it is relevant. - Don On Wed, 2007-01-10 at 21:01 +0100, Chrilly wrote: You must test with Gnu-Go level 16.. This is according to Stefan Mertin by far the best mode. But it takes sometimes quite a long time till Gnu-Go makes it move. In your experiments Gun-Go played very fast. You played fast Blitz and Gnu-Go had a big time handicap (besides Handtalk, which plays Ultra-Blitz). Chrilly - Original Message - From: Hiroshi Yamashita [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 10, 2007 6:10 PM Subject: [computer-go] Gnugo vs commercial programs I tested Gnugo against some commercial programs. Gnugo is 3.7.10. Level is default with --never-resign and --komi 6.5 option. Commercial program is max level. All game is Japanese rule and komi is 6.5. gnugo wins losses winning rate average score GinseiIgo5 (KCC Igo ) 1155 0.17 -31.3 points Saikouhou3 (Haruka ) 1344 0.23 -41.4 points TuyoiIgo4 (Go4++ ) 2754 0.33 -11.4 points ShudanTaikyoku3 (Handtalk) 2937 0.44 - 4.5 points GinseiIgo5 ... KCC Igo, published in 2004. Saikouhou3 ... Haruka, published in 2002. Latest version. TuyoiIgo4 ... Go4++,published in 2003. Engine is 2002 version. ShudanTaikyoku3 ... Handtalk, published in 1999. These are not latest version except Haruka. All game records are here. http://www.yss-aya.com/gnugo_vs_result.zip Average expended hours. KCC 17m51s Gnugo 3m14s, Opteron248(2.2GHz) Haruka 11m53s Gnugo 4m28s, Opteron248(2.2GHz) + AthlonXP 2100+(1.73GHz) Go4++ 4m59s Gnugo 2m18s, Opteron248(2.2GHz) Handtalk 2m42s Gnugo 5m22s, AthlonXP 2100+(1.73GHz) Appendix. GnuGo 3.5.4 (January, 2004 version) test result. Level is default. gnugo wins losses winning rate average score ValueIgo3 (KCC Igo ) 426 0.13 -36.6 points TuyoiIgo4 (Go4++) 1119 0.37 -6.5 points ShudanTaikyoku3 (Handtalk ) 1218 0.40 -3.8 points AI Igo2004 (ManyFaces) 1812 0.60 +11.7 points ValueIgo3 ... KCC Igo, published in 2003. same GinseiIgo2PW(2001?) AI Igo2004 ... ManyFaces, published in 2003. engine is 2003? --- Regards, Hiroshi Yamashita ___ 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/ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
On Wed, 2007-01-10 at 16:38 -0800, steve uurtamo wrote: in absolute terms, the time issue doesn't matter until some piece of code is good enough to beat a dan-level player on a 19x19 board at *any* physically realistic time constraint. which hasn't yet been demonstrated. the super slow motion tournament would be a good way for us to notice when this happens. Chrilly correctly points out that one of the programs tested played a lot faster than most of the others.Even if none them can beat a dan level player, what does this have to do with the big time advantage? My programs benefit enormously from extra time and if someone tested it playing at 1 second to another program playing at 1 minute I would probably view the test as unfair. Are you saying this would be fair because neither program can beat a 1 dan player? I don't get it. I like your idea of playing slow motion tournaments. Unfortunately, it's difficult getting humans involved to compare. But perhaps your stone handicap idea gives us a way to make rough comparisons. - Don (i.e when program X can give program Y 9 stones when program Y has a 30 minute time limit and program X has a 24 hour time limit, and they're normally much closer in strength when they both play at 30 minute time limits). as an example, if any program could give gnugo 9 stones under these circumstances, it might be good evidence that we're within a factor of 50x in speed of being capable of beating a 1d player. s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 10, 2007 7:24:38 PM Subject: Re: [computer-go] Gnugo vs commercial programs Chrilly, The computer go guys don't think of performance as a function of time, only as a kind of absolute, it plays good or it doesn't. Us computer chess people are used to thinking of it as a function of how fast the computer is and how much memory (along with how well the code is written of course.) The UCT programs, assuming they are properly coded and bug free, all play perfectly, but what really counts is how well they play given some time constraint. Again, most of the computer GO people do not think in those terms. It's very encouraging to me that Hiroshi reported the thinking times, I think he understands that it is relevant. - Don On Wed, 2007-01-10 at 21:01 +0100, Chrilly wrote: You must test with Gnu-Go level 16.. This is according to Stefan Mertin by far the best mode. But it takes sometimes quite a long time till Gnu-Go makes it move. In your experiments Gun-Go played very fast. You played fast Blitz and Gnu-Go had a big time handicap (besides Handtalk, which plays Ultra-Blitz). Chrilly - Original Message - From: Hiroshi Yamashita [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 10, 2007 6:10 PM Subject: [computer-go] Gnugo vs commercial programs I tested Gnugo against some commercial programs. Gnugo is 3.7.10. Level is default with --never-resign and --komi 6.5 option. Commercial program is max level. All game is Japanese rule and komi is 6.5. gnugo wins losses winning rate average score GinseiIgo5 (KCC Igo ) 1155 0.17 -31.3 points Saikouhou3 (Haruka ) 1344 0.23 -41.4 points TuyoiIgo4 (Go4++ ) 2754 0.33 -11.4 points ShudanTaikyoku3 (Handtalk) 2937 0.44 - 4.5 points GinseiIgo5 ... KCC Igo, published in 2004. Saikouhou3 ... Haruka, published in 2002. Latest version. TuyoiIgo4 ... Go4++,published in 2003. Engine is 2002 version. ShudanTaikyoku3 ... Handtalk, published in 1999. These are not latest version except Haruka. All game records are here. http://www.yss-aya.com/gnugo_vs_result.zip Average expended hours. KCC 17m51s Gnugo 3m14s, Opteron248(2.2GHz) Haruka 11m53s Gnugo 4m28s, Opteron248(2.2GHz) + AthlonXP 2100+(1.73GHz) Go4++ 4m59s Gnugo 2m18s, Opteron248(2.2GHz) Handtalk 2m42s Gnugo 5m22s, AthlonXP 2100+(1.73GHz) Appendix. GnuGo 3.5.4 (January, 2004 version) test result. Level is default. gnugo wins losses winning rate average score ValueIgo3 (KCC Igo ) 426 0.13 -36.6 points TuyoiIgo4 (Go4++) 1119 0.37 -6.5 points ShudanTaikyoku3 (Handtalk ) 1218 0.40 -3.8 points AI Igo2004 (ManyFaces) 1812 0.60 +11.7 points ValueIgo3 ... KCC Igo, published in 2003. same GinseiIgo2PW(2001?) AI Igo2004 ... ManyFaces, published in 2003. engine is 2003? --- Regards, Hiroshi Yamashita
Re: [computer-go] Gnugo vs commercial programs
I would suggest the minor correction to say that any non-GNU based program would have this hope. SlugGo already does this, but I doubt it has this meaning. Cheers, David On 10, Jan 2007, at 4:38 PM, steve uurtamo wrote: as an example, if any program could give gnugo 9 stones under these circumstances, it might be good evidence that we're within a factor of 50x in speed of being capable of beating a 1d player. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Gnugo vs commercial programs
I still don't understand your point. Are you just trying to say computers have a long way to go to beat really strong humans? If so, that doesn't have anything to do with what Chrilly said or my response to him. On Wed, 2007-01-10 at 19:10 -0800, steve uurtamo wrote: i'm saying that if a factor of 50 extra time can make your program strong enough to be 'impressive', then you know that you're within a reasonable hardware 'scaling distance' of playing that strong at regular timeframes. Ok, I understand this and agree. if, on the other hand, you're *not* (which would be easy to see by performing my experiment with the putatively scalable player getting the factor of 50 time advantage over a few otherwise similarly-ranked computer players who have normal time constraints) seeing a massive advantage with a factor of 50 time advantage, then you're *not* within a small scalable factor of having a piece of code which, whatever the technique and hardware, is objectively 'strong'. This is not what we were discussing, but I think I see your point. All you are saying is that we can measure how far we are from some arbitrary goal by playing very long time-control matches. given that the second is the case, worrying about performance as a function of time as opposed to worrying about absolute strength is a little bit silly. No, your argument is wrong. It's ONLY about performance as a function of time. Absolute strength has nothing to do with it as we already know how to make a perfect program. If your goal is to make a stronger program then you have to think in terms of how to make it play better moves in less time. to state this more simply, it only really matters to measure strength as a function of thinking time if changing the thinking time affects the level of play significantly. and given that it doesn't, it does make good sense to emphasize the 'absolute' level of play. Who said it doesn't? Hiroshi Yamashita posted the run times of the program. Multiply all of those times by 100 to see how LONG it would take to run on computers of just a few years ago.Either the programmers are getting stupid, or they actually have scaled their program up to modern hardware. Average expended hours. KCC 17m51s Gnugo 3m14s, Opteron248(2.2GHz) Haruka 11m53s Gnugo 4m28s, Opteron248(2.2GHz) + AthlonXP 2100 +(1.73GHz) Go4++ 4m59s Gnugo 2m18s, Opteron248(2.2GHz) Handtalk 2m42s Gnugo 5m22s, AthlonXP 2100+(1.73GHz) to see what i'm saying in action, if we were to dump a few copies of gnugo into a slow-motion tournament, one of which always played black with 2 stones handicap, one of which always played black with 3 stones handicap, etc., etc., and all of which were told that they only had, say, 30 minutes to make all of their moves (while their opponents were given 24 hours), we could see just how much stronger everyone's programs are *even with* a factor of 50 time advantage. GnuGo is probably not a very good example of a scalable program. It's a reasonably good program by today's standards, but it probably wouldn't play a lot better on a computer 1 billion times faster. I don't know where the tradeoff is with mogo vs gnugo, but Mogo is the strongest future program of the two - assuming neither one changes. Mogo would overtake gnugo on a computer you will buy in a few years. However, by then gnugo will have improved in some way - perhaps by being more mogo-like or doing something completely different - but whatever it is that it does different it will not run on today's computers - it will do a lot more calculations. my guess, after watching the last tournament, is that all of the players involved last time would still be within a few stones of gnugo -- that the factor of 50 time advantage didn't make anyone massively stronger. heck, i doubt that a factor of 50 time advantage would make *gnugo* more than a few stones stronger than itself. of course, all of this is easily verified. :) A few stones is a heck of a lot. If 1 stone is approximately 100 ELO points then a few stones is huge.A chess program gets about 60 ELO for a doubling - a factor of 50 times is only a few doublings, perhaps 300 ELO or 3 stones in GO terms. Of course this is all pretty crude estimates and it's hard to compare. 50 X speedup sound rather impressive but it's not that much. It's probably made go programs about 2 or 3 stones stronger over the few years that it took to get hardward 50X faster about what you would expect. You are not thinking straight if you think 50X speedup is supposed to make it more than 2 or 3 stones stronger. It's no wonder you are disappointed. I think the programs probably did play a lot stronger - it's just not that impressive when you compare it to 1 dan players (which I don't know why we insist on doing that.)It's a human perception issue - when someone sucks, we usually don't distinguish how much they
Re: [computer-go] Gnugo vs commercial programs
... when someone sucks, we usually don't distinguish how much they suck so even if they improve a lot, we still think they suck. And if you suck no one cares how much. He's right. I suck and no one cares. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
