Re: [computer-go] MoGo v.s. Kim rematch (Jason House's paper)
Sent from my iPhone On Sep 24, 2008, at 5:16 PM, Jason House [EMAIL PROTECTED] wrote: On Sep 24, 2008, at 2:40 PM, Jacques Basaldúa [EMAIL PROTECTED] wr ote: Therefore, the variance of the normal that best approximates the distribution of both RAVE and wins/(wins + losses) is the same n·p·(1-p) See above, it's slightly different. If this is true, the variance you are measuring from the samples does not contain any information about the precision of the estimators. If someone understands this better, please explain it to the list. This will get covered in my next revision. A proper discussion is too much to type with my thumb... My paper writing time is less than I hadhiped, so here's a quick and dirty answer. For a fixed win rate, the probabilities of a specific number of wins and losses follows the binomial distribution. That distribution keeps p (probability of winning) constant and the number of observed wins and losses variable. When trying to reverse this process, the wins and losses are kept constant and p varies. Essentially prob(p=x) is proportional to (x^wins)(1-x)^losses. This is a Beta distribution with known mean, mode, variance, etc... It's these values which should be used for approximating the win rate estimator as a normal distion. Does that makes sense? I've glossed over a very important detail when reversing. Bayes Theorem requires some extra a priori information. My preferred handling alters the reversed equation's exponents a bit but the basic conclusion (of a beta distribution) is the same.___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch (Jason House's paper)
On Fri, Sep 26, 2008 at 9:29 AM, Jason House [EMAIL PROTECTED] wrote: Sent from my iPhone On Sep 24, 2008, at 5:16 PM, Jason House [EMAIL PROTECTED] wrote: On Sep 24, 2008, at 2:40 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: Therefore, the variance of the normal that best approximates the distribution of both RAVE and wins/(wins + losses) is the same n·p·(1-p) See above, it's slightly different. If this is true, the variance you are measuring from the samples does not contain any information about the precision of the estimators. If someone understands this better, please explain it to the list. This will get covered in my next revision. A proper discussion is too much to type with my thumb... My paper writing time is less than I hadhiped, so here's a quick and dirty answer. For a fixed win rate, the probabilities of a specific number of wins and losses follows the binomial distribution. That distribution keeps p (probability of winning) constant and the number of observed wins and losses variable. When trying to reverse this process, the wins and losses are kept constant and p varies. Essentially prob(p=x) is proportional to (x^wins)(1-x)^losses. This is a Beta distribution with known mean, mode, variance, etc... It's these values which should be used for approximating the win rate estimator as a normal distion. Does that makes sense? I've glossed over a very important detail when reversing. Bayes Theorem requires some extra a priori information. My preferred handling alters the reversed equation's exponents a bit but the basic conclusion (of a beta distribution) is the same. Maybe I can say it a little more precisely. Before we have collected any data, let's use a uniform prior for p. After we sample the move a number of times, we obtain w wins and l losses. Bayes's theorem tells us that the posterior probability distribution is a beta distribution B(w+1,l+1) (see http://en.wikipedia.org/wiki/Beta_distribution for details). An implication of this is that the expected value of p after w wins and l losses is (w+1)/(w+l+2). This is the same as initializing w=l=1 before you have any information and then using w/(w+l) as your winning rate, which some people have done intuitively, but it's clear that it's not just a kludge. I'll use the letter r for the value of the winning rate. The estimate of the variance is (w+1)*(l+1)/((w+l+2)^2*(w+l+3)), which is r*(1-r)/(w+l+3). The simple UCB formula uses an estimate of the variance that is simply 1/visits, so perhaps one should modify the formula by multiplying that estimate by r*(1-r), which means that the variance is smaller in positions that look like clear victories for one side. I don't know if this makes any difference in practice, but I doubt it. Álvaro. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch (Jason House's paper)
Sent from my iPhone On Sep 27, 2008, at 10:14 AM, Álvaro Begué [EMAIL PROTECTED] wrote: On Fri, Sep 26, 2008 at 9:29 AM, Jason House [EMAIL PROTECTED] wrote: Sent from my iPhone On Sep 24, 2008, at 5:16 PM, Jason House [EMAIL PROTECTED] wrote: On Sep 24, 2008, at 2:40 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: Therefore, the variance of the normal that best approximates the distribution of both RAVE and wins/(wins + losses) is the same n·p·(1-p) See above, it's slightly different. If this is true, the variance you are measuring from the samples does not contain any information about the precision of the estimators. If someone understands this better, please explain it to the list. This will get covered in my next revision. A proper discussion is too much to type with my thumb... My paper writing time is less than I hadhiped, so here's a quick and dirty answer. For a fixed win rate, the probabilities of a specific number of wins and losses follows the binomial distribution. That distribution keeps p (probability of winning) constant and the number of observed wins and losses variable. When trying to reverse this process, the wins and losses are kept constant and p varies. Essentially prob(p=x) is proportional to (x^wins)(1- x)^losses. This is a Beta distribution with known mean, mode, variance, etc... It's these values which should be used for approximating the win rate estimator as a normal distion. Does that makes sense? I've glossed over a very important detail when reversing. Bayes Theorem requires some extra a priori information. My preferred handling alters the reversed equation's exponents a bit but the basic conclusion (of a beta distribution) is the same. Maybe I can say it a little more precisely. Before we have collected any data, let's use a uniform prior for p. After we sample the move a number of times, we obtain w wins and l losses. Bayes's theorem tells us that the posterior probability distribution is a beta distribution B(w+1,l+1) (see http://en.wikipedia.org/wiki/Beta_distribution for details). When I originally posted about this stuff and modifying the UCB formula, the uniform prior was a major sticking point for people. It is my preferred handling when no domain knowledge/heuristics are used. An implication of this is that the expected value of p after w wins and l losses is (w+1)/(w+l+2). This is the same as initializing w=l=1 before you have any information and then using w/(w+l) as your winning rate, which some people have done intuitively, but it's clear that it's not just a kludge. I'll use the letter r for the value of the winning rate. The estimate of the variance is (w+1)*(l+1)/((w+l+2)^2*(w+l+3)), which is r*(1-r)/(w+l+3). The simple UCB formula uses an estimate of the variance that is simply 1/visits, so perhaps one should modify the formula by multiplying that estimate by r*(1-r), which means that the variance is smaller in positions that look like clear victories for one side. I don't know if this makes any difference in practice, but I doubt it. The UCB1-Tuned formula aimed at a similar effect. I know the MoGo team abandoned it because they didn't see a strength gain, just added complexity. In fact, they don't even use UCB's at all anymore. Also, note that when initializing wins and losses to 1, n=wins+losses and p=wins/n, the variance becomes p(1-p)/(n+1) which is very close to a nieve binomial distribution of p(1-p)/n with win and loss initialization. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
On Sep 25, 2008, at 12:12 AM, David Fotland [EMAIL PROTECTED] games.com wrote: This is an interesting idea, but do you have any actual results? If you implement this kind of rave formula do you get a stronger program? I don't have enough data to say anything except that it did not have a large (100 ELO+) change. I switched to this method just before the July KGS tournament. Both the old and new versions were untuned, but based on parameters I've heard on this list. My testing on CGOS is tough to draw conclusions from. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Jason House Sent: Wednesday, September 24, 2008 4:34 AM To: computer-go Subject: Re: [computer-go] MoGo v.s. Kim rematch On Tue, 2008-09-23 at 18:08 -0300, Douglas Drumond wrote: Attached is a quick write up of what I was talking about with some math. PS: Any tips on cleanup and making it a mini publication would be appreciated. I've never published a paper before. Would this be too small? Better add an abstract, but what I missed most was bibliography. Ask and you shall receive :) Actually, I spent most of my free time learning Tex/Lyx, so there are very few changes in this version. I'm out of time for a while, so I figured I'd just share what I have so far. []'s Douglas Drumond - Computer Engineering FEEC/IC - Unicamp ___ 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] MoGo v.s. Kim rematch
This is an interesting idea, but do you have any actual results? If you implement this kind of rave formula do you get a stronger program? David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Jason House Sent: Wednesday, September 24, 2008 4:34 AM To: computer-go Subject: Re: [computer-go] MoGo v.s. Kim rematch On Tue, 2008-09-23 at 18:08 -0300, Douglas Drumond wrote: Attached is a quick write up of what I was talking about with some math. PS: Any tips on cleanup and making it a mini publication would be appreciated. I've never published a paper before. Would this be too small? Better add an abstract, but what I missed most was bibliography. Ask and you shall receive :) Actually, I spent most of my free time learning Tex/Lyx, so there are very few changes in this version. I'm out of time for a while, so I figured I'd just share what I have so far. []'s Douglas Drumond - Computer Engineering FEEC/IC - Unicamp ___ 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] MoGo v.s. Kim rematch
On 22, Sep 2008, at 10:50 PM, Hideki Kato wrote: David Doshay: [EMAIL PROTECTED]: It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Really previous Huygens used Ethernet? It's hard to believe... Hideki I thought so as well, but Olivier wrote to me: Begin forwarded message: From: Olivier Teytaud [EMAIL PROTECTED] Date: 6, September 2008 2:07:42 AM PDT To: David Doshay [EMAIL PROTECTED] Subject: Re: [computer-go] yet a mogo vs human game Hi David, ... We will have at least the same number of cores, probably more, and we will very likely have a better hardware - the infiniband network should be available, and this makes a big difference. ... Best regards, Olivier So, perhaps Huygens has both and they were not using it last time, or maybe they brought Huygens up with E-net and then upgraded. But Mogo did not use it for the Portland exhibition, but did use infiniband for the rematch. Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
David, I've found a description that Infiniband was improved from 2 x 4X IB (20 Gbps) to 8 x 8X IB (160 Gbps) on Jun 2008 at the bottom of 6th page of a pdf about Huygens system: https://www.os3.nl/_media/2007-2008/courses/inr/week7/sne_20080320_walter.pdf I guess that is the better hardware Olivier wrote. Hideki David Doshay: [EMAIL PROTECTED]: On 22, Sep 2008, at 10:50 PM, Hideki Kato wrote: David Doshay: [EMAIL PROTECTED]: It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Really previous Huygens used Ethernet? It's hard to believe... Hideki I thought so as well, but Olivier wrote to me: Begin forwarded message: From: Olivier Teytaud [EMAIL PROTECTED] Date: 6, September 2008 2:07:42 AM PDT To: David Doshay [EMAIL PROTECTED] Subject: Re: [computer-go] yet a mogo vs human game Hi David, ... We will have at least the same number of cores, probably more, and we will very likely have a better hardware - the infiniband network should be available, and this makes a big difference. ... Best regards, Olivier So, perhaps Huygens has both and they were not using it last time, or maybe they brought Huygens up with E-net and then upgraded. But Mogo did not use it for the Portland exhibition, but did use infiniband for the rematch. Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
On Mon, Sep 22, 2008 at 1:21 PM, Łukasz Lew [EMAIL PROTECTED] wrote: Hi, On Mon, Sep 22, 2008 at 17:58, Jason House [EMAIL PROTECTED] wrote: On Sep 22, 2008, at 7:59 AM, Magnus Persson [EMAIL PROTECTED] wrote: The results of the math are most easilly expressed in terms of inverse variance (iv=1/variance) Combined mean = sum( mean * iv ) Combined iv = sum( iv ) I'll try to do a real write-up if anyone is interested. I am very interested. :) Lukasz Attached is a quick write up of what I was talking about with some math. PS: Any tips on cleanup and making it a mini publication would be appreciated. I've never published a paper before. Would this be too small? RAVE.doc Description: MS-Word document ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
Attached is a quick write up of what I was talking about with some math. PS: Any tips on cleanup and making it a mini publication would be appreciated. I've never published a paper before. Would this be too small? Better add an abstract, but what I missed most was bibliography. []'s Douglas Drumond - Computer Engineering FEEC/IC - Unicamp ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. I thought Olivier had previously said there was very little overhead. E.g.: http://computer-go.org/pipermail/computer-go/2008-May/015068.html http://www.mail-archive.com/computer-go@computer-go.org/msg07953.html I took this 95% to mean that giving Mogo 760 (800x0.95) times the thinking time on a single core would be the same strength as Mogo on 800 cores. Assuming a rule of thumb that doubling the playouts is worth one rank (*), increasing network speed will surely have very little effect on the strength? Darren *: That is from memory of discussion here; I hope somebody will correct me with a more accurate thumb. We will have at least the same number of cores, probably more, and we will very likely have a better hardware - the infiniband network should be available, and this makes a big difference. -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/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] MoGo v.s. Kim rematch
Quoting Mark Boon [EMAIL PROTECTED]: Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? The interesting question is if there is a silly bug or something more sophisticated. I have struggled with ladders in Valkyria and it is often really hard to tell what causes these problems. In Leksand most games on 19x19 where lost in a ways similar to the recent mogo game. I could not find an obvious problem with the playouts at least not in terms of an easily fixable bug. Note that Valkyria reads out 99% of all ladders correctly both in the tree and in the playouts. What I realized was that AMAF in combination with heavy playouts causes some serious biases, for some kinds of very bad moves such that AMAF completely misevaluate them. In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
I'm curious about a couple of things in particular. Is this a bug and how much time would be required for Mogo to have played the correct move if it wasn't. Of course I'm also interested in ways to solve this with less deep searches or better play-outs. - Don On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon [EMAIL PROTECTED]: Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? The interesting question is if there is a silly bug or something more sophisticated. I have struggled with ladders in Valkyria and it is often really hard to tell what causes these problems. In Leksand most games on 19x19 where lost in a ways similar to the recent mogo game. I could not find an obvious problem with the playouts at least not in terms of an easily fixable bug. Note that Valkyria reads out 99% of all ladders correctly both in the tree and in the playouts. What I realized was that AMAF in combination with heavy playouts causes some serious biases, for some kinds of very bad moves such that AMAF completely misevaluate them. In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
I think AMAF is a feature not a bug. It's only a matter of how judiciously it's applied. Also, almost any evaluation feature in a game playing program is a bug - meaning it is an imperfect approximation of what you really want. Of course it could turn out that AMAF got them in trouble in this game. The Mogo team will probably analyze the reason for the problem.But as long as they are playing strong professional players they are going to have something to debug and analyze! - Don On Mon, 2008-09-22 at 06:06 -0700, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] MoGo v.s. Kim rematch
AMAF certainly helps to do move ordering when there is little other information. With good prior heuristics or enough actual playouts, it should not be weighted very highly. AMAF finds good moves, but it often bias heavily for or against moves. In ManyFaces, AMAF (actually RAVE) is worth between 5% and 10% wins against gnugo. I've seen similar ladder problems, and it is not AMAF, it's caused by the playouts, when they can't read ladders. It's easy to add various hacks to prevent playing out simple ladders, but the one in this game had an extra liberty (if I remember correctly). A general solution is a little tricky. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Don Dailey Sent: Monday, September 22, 2008 6:23 AM To: computer-go Subject: Re: [computer-go] MoGo v.s. Kim rematch I think AMAF is a feature not a bug. It's only a matter of how judiciously it's applied. Also, almost any evaluation feature in a game playing program is a bug - meaning it is an imperfect approximation of what you really want. Of course it could turn out that AMAF got them in trouble in this game. The Mogo team will probably analyze the reason for the problem.But as long as they are playing strong professional players they are going to have something to debug and analyze! - Don On Mon, 2008-09-22 at 06:06 -0700, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. Congratulations to the Mogo team; good luck improving your program to deal with the ladder and life-and-death issues. Looking forward to further information! I have always wondered if AMAF is a feature or a bug. There are many situations where the order of moves is crucial; A before B wins, B before A loses; ladders are a classic example where the ordering of moves is utterly important. AMAF seems to assume that order doesn't matter. Of course, there are many other positions where this assumption is true; that is why it sometimes yields an improvement in processing speed, but it seems risky. Ladders are also a classic case where two patterns can look very similar, but be very different. When you capture a ladder, you are in a very good position. But if the stones under attack have just one extra liberty, the position may look like a ladder, but your target will escape, and your stones will be full of cutting points; the proper evaluation for that position would be much harsher. More generally, whenever I see a Monte Carlo program lose, it is usually a semeai where being one liberty behind or one ahead makes all the difference. We call these capturing races in English for a reason; being ahead or behind by one liberty matters a great deal. To make life interesting, there are loose ladder constructs where an extra liberty does not help the fleeing stones; they still get corraled and captured. These corner cases are tough, but many games hinge on correctly reading out the exact consequences of life-and-death struggles. Terry McIntyre [EMAIL PROTECTED] Go is very hard. The more I learn about it, the less I know. -Jie Li, 9 dan On Mon, 2008-09-22 at 13:59 +0200, Magnus Persson wrote: Quoting Mark Boon : Playing out that fake ladder in the first game meant an instant loss. Surprising. And embarassing. Any information on the number of processors used? ___ 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] MoGo v.s. Kim rematch
On Sep 22, 2008, at 7:59 AM, Magnus Persson [EMAIL PROTECTED] wrote: In the case of the ladders the heavy playouts of Valkyria correctly prunes playing out ladders for the loser. But sometimes in the playouts the ladder is broken and after that there is a chance that the stones escape anyway. This means that almost always when the escaping move is played it is a good move! Thus AMAF will assign a very good score to this move My solutions to this was simply to turn off AMAF-eval for all shapes commonly misevaluated for ladders. But I think this problem is true for many shapes in general. What makes ladders special is that the problem repeats it self and the effect get stronger and thus even more likely the larger the ladder gets. I think a better solution would be to modify AMAF in some way to avoid these problems, or perhaps change the playouts in a way to balance the problem. Does anyone know something to do about it or have any ideas? My RAVE formulation includes a per-move parameter for RAVE confidence. This allows heuristics to fix situations like above. Sadly, my bot isn't mature enough to take advantage yet :( The concept I used for the derivation is simple. I treat everything as gaussian estimators. It's easy to find the max of the distribution. I then use the same trick as bayeselo to estimate variance. I then add a Gaussian noise term to represent RAVE bias. The results of the math are most easilly expressed in terms of inverse variance (iv=1/variance) Combined mean = sum( mean * iv ) Combined iv = sum( iv ) I'll try to do a real write-up if anyone is interested. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Cheers, David On 22, Sep 2008, at 6:06 AM, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
David Doshay: [EMAIL PROTECTED]: It was 800, just like last time, but the networking had been upgraded from ethernet to infiniband. Olivier said that this should have been a good improvement because he felt that communication overhead was significant. Really previous Huygens used Ethernet? It's hard to believe... Hideki Cheers, David On 22, Sep 2008, at 6:06 AM, terry mcintyre wrote: Consider this as tentative, since I heard it about 3rd-hand, but I believe the number of processors used to have been 3000. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MoGo v.s. Kim rematch
Anyone knows the result, or better the game sgf? On Sat, Sep 6, 2008 at 6:57 AM, Don Dailey [EMAIL PROTECTED] wrote: Great news! Look forward to seeing it happen. I hope Mogo has some great hardware. - Don On Fri, 2008-09-05 at 15:54 -0700, David Doshay wrote: MoGo and Myungwan Kim will hold an exhibition rematch at the Cotsen Open on Saturday September 20. The exhibition will start at about 5pm Pacific Daylight time. As probably known by all on this list, MoGo won the last game, held at the US Go Congress in Portland Oregon, when it was given a 9 stone handicap and played with a one hour time limit. At this time the expected handicap will be 7, and it is not clear if there will be one game or two. It is not known at this time how many cores MoGo will be running on. Mr Kim has asked for MoGo to be given 90 minutes because he saw how much the increase in time from 15 minutes to one hour increased its playing strength. Mr. Kim has also asked that there be only one or at most 2 blitz games at the start. The MoGo team also wants to have some 9x9 games, but Mr Kim does not feel familiar enough with 9x9 to play those games, but he is searching for an alternate strong player. MoGo has some new features for 9x9, and the team is anxious to see the newest code in action. Cheers, David ___ 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] MoGo v.s. Kim rematch
There is a discussion at godiscussions http://www.godiscussions.com/forum/showthread.php?t=7154 ?The sgf's for the two games played are on page 2 Dave Hillis -Original Message- From: mingwu [EMAIL PROTECTED] To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org Sent: Sun, 21 Sep 2008 9:22 pm Subject: Re: [computer-go] MoGo v.s. Kim rematch Anyone knows the result, or better the game sgf? On Sat, Sep 6, 2008 at 6:57 AM, Don Dailey [EMAIL PROTECTED] wrote: Great news! ? Look forward to seeing it happen. ?I hope Mogo has some great hardware. - Don On Fri, 2008-09-05 at 15:54 -0700, David Doshay wrote: MoGo and Myungwan Kim will hold an exhibition rematch at the Cotsen Open on Saturday September 20. The exhibition will start at about 5pm Pacific Daylight time. As probably known by all on this list, MoGo won the last game, held at the US Go Congress in Portland Oregon, when it was given a 9 stone handicap and played with a one hour time limit. At this time the expected handicap will be 7, and it is not clear if there will be one game or two. It is not known at this time how many cores MoGo will be running on. Mr Kim has asked for MoGo to be given 90 minutes because he saw how much the increase in time from 15 minutes to one hour increased its playing strength. Mr. Kim has also asked that there be only one or at most 2 blitz games at the start. The MoGo team also wants to have some 9x9 games, but Mr Kim does not feel familiar enough with 9x9 to play those games, but he is searching for an alternate strong player. MoGo has some new features for 9x9, and the team is anxious to see the newest code in action. Cheers, David ___ 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] MoGo v.s. Kim rematch
Great news! Look forward to seeing it happen. I hope Mogo has some great hardware. - Don On Fri, 2008-09-05 at 15:54 -0700, David Doshay wrote: MoGo and Myungwan Kim will hold an exhibition rematch at the Cotsen Open on Saturday September 20. The exhibition will start at about 5pm Pacific Daylight time. As probably known by all on this list, MoGo won the last game, held at the US Go Congress in Portland Oregon, when it was given a 9 stone handicap and played with a one hour time limit. At this time the expected handicap will be 7, and it is not clear if there will be one game or two. It is not known at this time how many cores MoGo will be running on. Mr Kim has asked for MoGo to be given 90 minutes because he saw how much the increase in time from 15 minutes to one hour increased its playing strength. Mr. Kim has also asked that there be only one or at most 2 blitz games at the start. The MoGo team also wants to have some 9x9 games, but Mr Kim does not feel familiar enough with 9x9 to play those games, but he is searching for an alternate strong player. MoGo has some new features for 9x9, and the team is anxious to see the newest code in action. Cheers, David ___ 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/
