[computer-go] 19x19 MC improvement
My program Aya637_4CPU is top on 19x19 CGOS now. It is temporary, but I'm so happy! Please don't run full power MoGo, Crazy Stone and Leela :-) My main improvement was 1. Do not move dead stones. Before doing playout, Aya does string capture search up to 7 plies(ladders are extended). And set the probability of dead stones's liberty to 1/1. This changed winning rate 0.17 to 0.33 (both are 200 games, 4po against GnuGo 3.7.10) But in 9x9, this method changed nothing. There is no ladder search in playout. 2. Change UCT exploration parameter exp_param = sqrt(2.0); uct = exp_param * sqrt( log(sum of all children playout) / (number of child playout) ); uct_value = (child winning rate) + uct; I changed exp_param sqrt(2.0) to sqrt(0.1). This changed winning rate 0.10(660 games) to 0.22(140 games). (1po, against GnuGo 3.7.10) I was surprised such a small parameter change made big difference. AyaMC's sytle is similar to Crazy Stone. - progressive windening. - pattern is only 3x3 from 1 professional player's game. Uct code is like this, http://www.yss-aya.com/uct_aya_e.cpp In 1po of the root initial position, 11 nodes are created, and 18 candidates are searched Regards, Hiroshi Yamashita ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable ... is a troll
Le mercredi 23 janvier 2008, ivan dubois a écrit : Hi Alain, Sorry for being so insistant : You should browse the archive of the list, nearly the same discussion about infinite and scalability happenned in 2007. No i just said that, unless i really understood nothing, i read here from well known competent persons that MC+UCT scales infinitely , and would reach perfect play with infinite computational resources, and this is theoretically proven (which is not the case for classical program like our beloved GNU Go). This is absolutely true. Now this can also be said for a mini-max solver (my point). Don Dailey answered better than i could do, yes minimax also scales. So MC+UCT scales. (even against humans, martians, trolls, computers, gods ... :) The conclusion does not follow. Ah ? Why not ? what is wrong in the reasonning ? Should i think : It scales in theory so it does NOT scale in practice ? The fact that it eventualy reaches perfect play with enough computing power does NOT mean that it scales well. Proof : A mini-max solver does reach perfect play with enough computing power BUT does not scale. we dont have the same informations. For Minimax scales too, maybe the improvement curve has a smaller slope than MC+UCT curve, but Actualy, this theoritical property is a NESCESSARY condition for UCT to scale, but it is not a SUFFICIANT condition. The scalability of UCT has been proven by its outstanding results From a pure logical point of vue - Positive experiment are never a valid proof. They are only examples that makes one feel his theory is right. - Only counter example are proof that the theory is wrong. and Don's experiments, not by mathematics. Are you a troll ? Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] 19x19 MC improvement
Congratulations! I'm really impressed with how fast the AyaMC improved. Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Hiroshi Yamashita Sent: Wednesday, January 23, 2008 12:12 AM To: computer-go Subject: [computer-go] 19x19 MC improvement My program Aya637_4CPU is top on 19x19 CGOS now. It is temporary, but I'm so happy! Please don't run full power MoGo, Crazy Stone and Leela :-) My main improvement was 1. Do not move dead stones. Before doing playout, Aya does string capture search up to 7 plies(ladders are extended). And set the probability of dead stones's liberty to 1/1. This changed winning rate 0.17 to 0.33 (both are 200 games, 4po against GnuGo 3.7.10) But in 9x9, this method changed nothing. There is no ladder search in playout. 2. Change UCT exploration parameter exp_param = sqrt(2.0); uct = exp_param * sqrt( log(sum of all children playout) / (number of child playout) ); uct_value = (child winning rate) + uct; I changed exp_param sqrt(2.0) to sqrt(0.1). This changed winning rate 0.10(660 games) to 0.22(140 games). (1po, against GnuGo 3.7.10) I was surprised such a small parameter change made big difference. AyaMC's sytle is similar to Crazy Stone. - progressive windening. - pattern is only 3x3 from 1 professional player's game. Uct code is like this, http://www.yss-aya.com/uct_aya_e.cpp In 1po of the root initial position, 11 nodes are created, and 18 candidates are searched 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/
Re: [computer-go] New scalability study : show uncertainty ?
On Tue, Jan 22, 2008 at 09:51:11PM +0100, Alain Baeckeroot wrote: Le mardi 22 janvier 2008, Michael Williams a écrit : ... perhaps only uniformly random playouts will scale to perfection. The reason that MC/UCT scales to perfection is because of the UCT part, not the MC (playout) part. People seems to forget this a lot. I agree on this _only_ if the UCT check all possible moves. If not one can be limited by the quality of the playout. I think we may be confusing two different things here: a) Using all possible moves in the playouts to evaluate a leaf in the UCT tree b) Making the UCT search all possible moves in a position These two are related, and I suspect often people use the same code for listing the possible moves, so they tend to be the same in many programs. Theoretically speaking, errors and bias in those two may well result in different things. Most MC implementations (that I know of) avoid playing in one-point eyes. That is alrady a deviation from all legal moves, but one that makes perfectly good sense. Yet there is at least one exception, where playing into an one-point eye can create a nakade, and kill a surrounding group... The selection of possible moves for a node in the UCT tree can be somewhat slower, since it is not done nearly as often. Also, adding bad moves here costs less than in the MC playout, since the UCT algorithm can see that they will not lead anywhere, and not give them so much attention. I don't (yet?) have an UCT program, so I can not test this. Some day when I have one, I will try to see how much it will help or hurt to try all legal moves in the UCT portion... If someone else tries it before, let us all know! - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable ... is a troll
On Tue, Jan 22, 2008 at 05:17:48PM -0500, [EMAIL PROTECTED] wrote: Don't make too much of it. A 2-Dan program will play 2-Dan games, not just occasionally generate a 2-Dan move. :) True. Most weak beginners start the game with a move that is often seen in professional play. Usually 3-3, 3-4, or 4-4. -H -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
Quoting Heikki Levanto [EMAIL PROTECTED]: I agree on this _only_ if the UCT check all possible moves. If not one can be limited by the quality of the playout. I think we may be confusing two different things here: a) Using all possible moves in the playouts to evaluate a leaf in the UCT tree b) Making the UCT search all possible moves in a position These two are related, and I suspect often people use the same code for listing the possible moves, so they tend to be the same in many programs. Indeed, Valkyria, uses the same code to prune move in both the playouts and in the UCT-tree. This pruning is supposed to be 100% safe and applies to really bad and ugly moves. But it is really hard to do this right and I still find a lot of bugs of this kind. There is an advantage of using the same code in the UCT-part because when I watch the program play I can see mistakes in pruning which otherwise only would be unseen in the playouts. In the latest version of Valkyria I make the exception that all moves are allowed if there is a ko fight, but I do not know if this is necessary at all. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
On Wed, Jan 23, 2008 at 11:18:37AM +0100, Magnus Persson wrote: Indeed, Valkyria, uses the same code to prune move in both the playouts and in the UCT-tree. This pruning is supposed to be 100% safe and applies to really bad and ugly moves. But you still prune moves like filling a one-point eye. We know that there is a pthological case where that indeed is a correct move. So Valkyria will never converge to perfect play even with unlimited CPU power. But it is really hard to do this right and I still find a lot of bugs of this kind. There is an advantage of using the same code in the UCT-part because when I watch the program play I can see mistakes in pruning which otherwise only would be unseen in the playouts. That is a valid point. Not to the theoretical discussion, but in practical everyday life! -H -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
Quoting Heikki Levanto [EMAIL PROTECTED]: But you still prune moves like filling a one-point eye. We know that there is a pthological case where that indeed is a correct move. So Valkyria will never converge to perfect play even with unlimited CPU power. Yes, this is a known bug. :) But, I will not fix it until I fixed some more urgent stuff (there is a very long list with higher priority). Also I feel that in the case of having a really strong program attempting perfect play with this bug as the only defect, the opponent has be extremely strong (or extremely lucky) to exploit it. It might even not be possible to exploit aginst perfect play, because there may always be simpler ways to kill the group than making en eye and then fill it, alternatively let it live small and win on points. MoGo is a good example of this. I think Valkyria has an edge against MoGo in many LD situations, but often MoGo just put territorial pressure on the groups leading to positions where the opponent either defends and loses on points or take a gamble, tenuki and die without tactical complications. Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability study - how close to perfection?
In message [EMAIL PROTECTED], Russ Williams [EMAIL PROTECTED] writes A couple of technical nitpick questions: On Jan 23, 2008 5:57 AM, David Fotland [EMAIL PROTECTED] wrote: Since the komi contains a half point, there should be almost no ties, How should there be almost no ties, instead of no ties, with the half point in the komi? (Or are you thinking of rulesets that award half-points for seki situations and such?) I know of no current rule set that assigns fractions of points in sekis, except to assign half a point to each player (which still results in an integer when you subtract one player's score from the other). The SST (Ing) rules used to assign other fractions, but do not now do so. I am not aware of a position under old SST rules such that the score difference could end up as exactly half a point, but there may be one. However, some rule sets treat a game that enters an infinite cycle as a draw. Current Chinese rules, as applied in Chinese professional events, are like this. Nick between two perfect players, one color will always win by half a point. Is this actually provably true in the mathematical sense? I agree it has intuitive appeal, but on the face of it, it seems possible that a perfectly played game could involve a fight over a big dragon, resulting in a large score difference. Perfect play on very small boards doesn't always result in very close final scores, right? Maybe part of the problem is I'm not 100% sure what perfect play means for a player who loses. :) cheers russ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability study - how close to perfection?
This bias was clear in 7x7 - I don't expect to see it here but I will check when there are enough games at the upper levels. - Don David Fotland wrote: Since the komi contains a half point, there should be almost no ties, and between two perfect players, one color will always win by half a point. In your scalability study, as the number of playouts goes up, is there a bias toward one color winning more than half the games? If so, it would show that the programs are getting close to optimal play. If they are close to optimal play it would explain the scaling curve flattening out. 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/
Re: [computer-go] New scalability study : show uncertainty ?
I don't think only uniformly random playouts will scale to perfection because what we need for playouts is not just a simple average of final scores but a maximum (in negmax sense) score. It should be the perfect evaluation function. In other words, as MC simulation is a way to get an average of a value, when applying it to optimization problems we need some way to focus the simulations to the _peak_ in a state space. It may be obvious when one consideres LD problems where the best move that leads to the maximum score (live) is only one and all other moves are bad. At such positions it's almost no sense to simulate all legal moves with same probability. So, IMHO, biasing simulations is not just a speed-up technique but is essentially important. I agree, but what I meant about uniformly random playouts is the following: What makes a move outstanding is being unpredictable. For a total novice, playing at the key point of a bulky five may look like a touch of genius, but when you learn a little, its an obvious move. The difference between a 5p and a 9p may be one or two moves nobody can predict (except a 9p). When we add knowledge we find the _ordinary_ good moves faster, we make weaker moves less probable, but that comes at a price, the price of making outstanding unpredictable moves less probable also. Perhaps that introduces a ceiling. I thought that was what you were also pointing. Of course, I don't claim uniformly random playouts are good, I just claim that they should (just as an infeasible theoretic argument) scale to perfection, of course that scaling doesn't have to be linear. Jacques. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] mathematical morphology
On Jan 23, 2008 1:47 PM, Jacques Basaldúa [EMAIL PROTECTED] wrote: Erik van der Werf wrote: You may also be interested in my article on estimating potential territory I am. Can you post a link, please. sure, it's all at: http://erikvanderwerf.tengen.nl/publications.html My thesis contains the latest version (see chapter 10); the original article is mostly the same, and can be downloaded from: http://erikvanderwerf.tengen.nl/pubdown/predicting_territory.pdf Erik ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : [computer-go] Is MC-UCT really scalable ... is a troll
Duhhh ! When I say a minimax solver, I mean a program witch returns a random move UNTIL it has completed its search, as I explained in a previous post. You all agreed this program didnt scale, so why are you saying, all of a sudden, that it DOES scale now !? Anyway I'm fed up with this discussion now, this is so too much pain and way too frustrating. - Message d'origine De : Alain Baeckeroot [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 9h15mn 41s Objet : Re: [computer-go] Is MC-UCT really scalable ... is a troll Le mercredi 23 janvier 2008, ivan dubois a écrit : Hi Alain, Sorry for being so insistant : You should browse the archive of the list, nearly the same discussion about infinite and scalability happenned in 2007. No i just said that, unless i really understood nothing, i read here from well known competent persons that MC+UCT scales infinitely , and would reach perfect play with infinite computational resources, and this is theoretically proven (which is not the case for classical program like our beloved GNU Go). This is absolutely true. Now this can also be said for a mini-max solver (my point). Don Dailey answered better than i could do, yes minimax also scales. So MC+UCT scales. (even against humans, martians, trolls, computers, gods ... :) The conclusion does not follow. Ah ? Why not ? what is wrong in the reasonning ? Should i think : It scales in theory so it does NOT scale in practice ? The fact that it eventualy reaches perfect play with enough computing power does NOT mean that it scales well. Proof : A mini-max solver does reach perfect play with enough computing power BUT does not scale. we dont have the same informations. For Minimax scales too, maybe the improvement curve has a smaller slope than MC+UCT curve, but Actualy, this theoritical property is a NESCESSARY condition for UCT to scale, but it is not a SUFFICIANT condition. The scalability of UCT has been proven by its outstanding results From a pure logical point of vue - Positive experiment are never a valid proof. They are only examples that makes one feel his theory is right. - Only counter example are proof that the theory is wrong. and Don's experiments, not by mathematics. Are you a troll ? Alain ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : [computer-go] Is MC-UCT really scalable ... is a troll
On Jan 23, 2008 2:45 PM, ivan dubois [EMAIL PROTECTED] wrote: When I say a minimax solver, I mean a program witch returns a random move UNTIL it has completed its search, as I explained in a previous post. A plain minimax solver (without enhancements like iterative deepening) doesn't return anything until it has completed its search. E. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Bent four in the corner was:Scalability problem of play-out policies
Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to do something with the weighting in these situations, so that the relevant moves are added to the tree. In worst case, a lot of effort is wasted in proving a bad move bad - but this should not be so serious, as the bad move will likely mean the opponent has poor chances of winning anyway. In the best case, the program's blunder is revealed after the fact. This may still leave little chance of winning, (if the ld error was severe) but at least the program's counting won't be off for the rest of the game. Since today's programs don't care for winning margins, counting errors by even a single point will spell disaster. I believe this heurtistic would be cheap in terms of computational cost, but hard to evaluate/tune. Self-play would not be very effective... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
Ok, this is a special minimax solver. Call it the Ivan Dubois stupid minimax solver if you like. Anyway, its only purpose is to show that : Returns the best move when given enough time does NOT implie Is scalable in practice. I am very sad that this simple logic has no appeal to most people on this list. - Message d'origine De : Erik van der Werf [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h21mn 37s Objet : Re: Re : [computer-go] Is MC-UCT really scalable ... is a troll On Jan 23, 2008 2:45 PM, ivan dubois [EMAIL PROTECTED] wrote: When I say a minimax solver, I mean a program witch returns a random move UNTIL it has completed its search, as I explained in a previous post. A plain minimax solver (without enhancements like iterative deepening) doesn't return anything until it has completed its search. E. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Bent four in the corner was:Scalability problem of play-out policies
On Wed, 23 Jan 2008, Harald Korneliussen wrote: It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. Just a quick note that an algorithm how to evaluate bent four like positions with a minimax search is given in http://lie.math.brocku.ca/twolf/papers/bent4.pdf Thomas ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Bent four in the corner was:Scalability problem of play-out policies
From: Harald Korneliussen [EMAIL PROTECTED] I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf Thanks for the example! That's the infamous square four - under any ruleset, it is absolutely and irrefutably dead. Mogo mis-evaluated the group as alive, and believed the score to be a win by 6.5. Since the group was dead, Mogo actually lost by 15.5 ( by area counting ) A white play at B1, move 195, was predictable. Had Mogo correctly anticipated and evaluated this nakade, it could have created a more robust shape. Terry McIntyre [EMAIL PROTECTED] Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to do something with the weighting in these situations, so that the relevant moves are added to the tree. In worst case, a lot of effort is wasted in proving a bad move bad - but this should not be so serious, as the bad move will likely mean the opponent has poor chances of winning anyway. In the best case, the program's blunder is revealed after the fact. This may still leave little chance of winning, (if the ld error was severe) but at least the program's counting won't be off for the rest of the game. Since today's programs don't care for winning margins, counting errors by even a single point will spell disaster. I believe this heurtistic would be cheap in terms of computational cost, but hard to evaluate/tune. Self-play would not be very effective... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to do something with the weighting in these situations, so that the relevant moves are added to the tree. In worst case, a lot of effort is wasted in proving a bad move bad - but this should not be so serious, as the bad move will likely mean the opponent has poor chances of winning anyway. In the best case, the program's blunder is revealed after the fact. This may still leave little chance of winning, (if the ld error was severe) but at least the program's counting won't be off for the rest of the game. Since today's programs don't care for winning margins, counting errors by even a single point will spell disaster. I believe this heurtistic would be cheap in terms of computational cost, but hard to evaluate/tune. Self-play would not be very effective... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] New scalability study : show uncertainty ?
Filling suc an eye does not require an extremely strong opponent; I am rated a mere 9 kyu AGA, and use this method often. My opponents also use it every chance they get. When teaching 20 kyu players, these known-dead shapes are right at the top of the list. However, several otherwise strong programs appear to have a blind spot regarding these situations. - Original Message From: Magnus Persson [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Wednesday, January 23, 2008 4:03:26 AM Subject: Re: [computer-go] New scalability study : show uncertainty ? Quoting Heikki Levanto [EMAIL PROTECTED]: But you still prune moves like filling a one-point eye. We know that there is a pthological case where that indeed is a correct move. So Valkyria will never converge to perfect play even with unlimited CPU power. Yes, this is a known bug. :) But, I will not fix it until I fixed some more urgent stuff (there is a very long list with higher priority). Also I feel that in the case of having a really strong program attempting perfect play with this bug as the only defect, the opponent has be extremely strong (or extremely lucky) to exploit it. It might even not be possible to exploit aginst perfect play, because there may always be simpler ways to kill the group than making en eye and then fill it, alternatively let it live small and win on points. MoGo is a good example of this. I think Valkyria has an edge against MoGo in many LD situations, but often MoGo just put territorial pressure on the groups leading to positions where the opponent either defends and loses on points or take a gamble, tenuki and die without tactical complications. Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
Hello, I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). However, and this can be surprising, I am not sure wether it is really a scalability killer for whole board play, because after all, it doesnt have to know with 100 % confidence the status of one group to play perfectly. - Message d'origine De : terry mcintyre [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 16h24mn 53s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to do something with the weighting in these situations, so that the relevant moves are added to the tree. In worst case, a lot of effort is wasted in proving a bad move bad - but this should not be so serious, as the bad move will likely mean the opponent has poor chances of winning anyway. In the best case, the program's blunder is revealed after the fact. This may still leave little chance of winning, (if the ld error was severe) but at least the program's counting won't be off for the rest of the game. Since today's programs don't care for winning margins, counting errors by even a single point will spell disaster. I believe this heurtistic would be cheap in terms of computational cost, but hard to evaluate/tune. Self-play would not be very effective... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
it will only assign it a positive probability of being dead if there are playouts where the group dies, right? s. - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 10:51:52 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). However, and this can be surprising, I am not sure wether it is really a scalability killer for whole board play, because after all, it doesnt have to know with 100 % confidence the status of one group to play perfectly. - Message d'origine De : terry mcintyre [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 16h24mn 53s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to do something with the weighting in these situations, so that the relevant moves are added to the tree. In worst case, a lot of effort is wasted in proving a bad move bad - but this should not be so serious, as the bad move will likely mean the opponent has poor chances of winning anyway. In the best case, the program's blunder is revealed after the fact. This may still leave little chance of winning, (if the ld error was severe) but at least the
Re: [computer-go] Is MC-UCT really scalable against humans?
On Jan 22, 2008, at 2:08 PM, [EMAIL PROTECTED] wrote: MoGo plays unconventional moves only in the first 10 moves or so. That is it plays an unconventional openning. An unconventional opening in Go is actaully something that is celebrated for ... DL If this is a concern, someone should add a fuseki database to a UCT program to see if it improves play. I know that Howard Landman had a very complete fuseki DB in his program Poka. I also wonder how Monte Carlo evaluations would work married to other depth-first searches, like Proof-Number. Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
Hi, This is correct. Do you think there will be no playouts where the group dies ? I think there will be around 50% where the group dies. If you think this is not the case, please explain to me. Ivan - Message d'origine De : steve uurtamo [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 17h22mn 35s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies it will only assign it a positive probability of being dead if there are playouts where the group dies, right? s. - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 10:51:52 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). However, and this can be surprising, I am not sure wether it is really a scalability killer for whole board play, because after all, it doesnt have to know with 100 % confidence the status of one group to play perfectly. - Message d'origine De : terry mcintyre [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 16h24mn 53s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth including into the tree, so that UCT catches them very late, if ever. If these situations can be reliably created by a human, then indeed they put an upper limit on the real world scalability of a program. If I should propose a hackish heuristic to deal with such situations, this is it: At one point, when the problematic shape appeared, the human must have done a move that to the computer seemed horribly bad. Why did he do that? Doesn't he see that my shape is alive?. When such situations occur, there are two possibilities: 1. The bot is playing a weaker human player, and the move is indeed bad. 2. The bot is playing a stronger human, and the move is actually good. I think it may be a good idea to
Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
I disagree. If the opponent's estimate of the rest of the board is at least as good as program XXX, but the opponent knows a particular group is 100% dead, where program XXX thinks it might live, the opponent is likely to win, with a probability approaching 1.00. Program XXX will be basing its decisions on provably false information. The opponent will spend just enough effort to keep that group dead, and will otherwise play as well as program XXX on the rest of the board. We have all seen that Mogo is not greedy - it will play suboptimal moves while it thinks it has the win. I've read many an argument about how Mogo is actually maximizing win probability; this is total fantasy. When obvious yose ( endgame ) plays or life-making plays are passed up in favor of tossing random stones into perfectly secure eyespace, that is a losing strategy. Better yose handling can ( and often does ) make up for earlier mistakes. Random stones in one's own area will not help. Under area counting rules, playing the da me ( neutral points ) would be better. Terry McIntyre [EMAIL PROTECTED] “Wherever is found what is called a paternal government, there is found state education. It has been discovered that the best way to insure implicit obedience is to commence tyranny in the nursery.” Benjamin Disraeli, Speech in the House of Commons [June 15, 1874] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:51:52 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). However, and this can be surprising, I am not sure wether it is really a scalability killer for whole board play, because after all, it doesnt have to know with 100 % confidence the status of one group to play perfectly. - Message d'origine De : terry mcintyre [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 16h24mn 53s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd looked at, where something very similar happened, and with a little digging I found it again: http://files.gokgs.com/games/2007/12/1/Ardalan-MoGoBot3.sgf It turns out it's not the bent four shape, but I suspect it's another such shape, where more playouts only confirm that these moves aren't worth
Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll
On Jan 23, 2008 3:44 AM, Don Dailey [EMAIL PROTECTED] wrote: This is still nonsense. UCT in actual real world PRACTICE responds dramatically to more hardware, how can you say it's not clear whether it's scalable in practice? In fairness, he didn't say that. What he said was that our belief regarding whether or not UCT scales in practice, should be based on tests on real hardware (which appear to give an answer in the affirmative), rather than on a mathematical proof of what happens in the limit as computer time tends to infinity (because what happens in the limit as time tends to infinity, doesn't necessarily have much bearing on what happens on real hardware; so tests are more informative). ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Is MC-UCT really scalable against humans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sure, 9x9 Go is still a very interesting game. One that can be a challenge even for the strongest players in the world. But in my opinion it's not nearly as interesting as 19x19 Go. Now if that's a point you'd like to argue, fine. But no need to be so patronizing. The interesting point here is not wether player A likes 9x9 or not. The question is if 19x19 go has properties that are different and relevant for computer go programs. In principle I think there is no difference between 9x9 and 19x19. Humans may deal with the complexity of 19x19 go in a way that is different from what they do on 9x9 go. But then I would say that a human player that play a lot of 9x9 would develop knowledge that only applies to 9x9, but from that I would not conclude that 9x9 is special compared to 19x19. It all boils down to unique positions that has to be analyzed with go knowledge that applies to all sizes of the game. So feel free to argue that 19x19 has properties that are unique, but in doing so please *specify* exactly what this means and why a computer program has to deal with it to play really strong. -Magnus The problem here and elsewhere on the computer-go eList appears to be the avoidance (for whatever reasons) of coming to an understanding of a general theory of _emergence_; and as it applies to gameplay in this case -- especially regarding Go. Sure, the rules themselves are the same with both 9x9, 13x13 and 19x19 boardsizes; but it's most likely that _new pattern relations emerge_ in time and space, with the more complex development of stone formations, the bigger the board gets. And that's what's not being properly and explicitly recognized here: thus all the misunderstanding and flip flop of positions to take, 'pro or con', as if matters are only one way with each board size, or with which algorithm or whatever -- and that's that. And so then this problem with emergence and dialectics very much spills over into the problems people here are having with what to focus on in the programming end of things too. 'Eithor/or' decisions don't often seem to be the best way to go about approaching problems. And this IMO logical defect has everything to do with the long reductionist history of programming and science whcih still plagues universities and research. My 2 cents-worth on this. - -- grok. - -- *** SOCIALISM OR BARBARISM ? *** * Capitalism wraps itself in flags of convenience * Critical * * The latest one is religious obscurantism * Support only * STEM THE ASSAULT ON MATERIALIST SCIENCE * http://richarddawkins.net/foundation Richard Dawkins Foundation * * http://www.talkorigins.org Talk.Origins *** for Reason Science * * http://www.darwin.ws Darwin World Site A Child's Primer of * * http://mrzine.monthlyreview.org/day240805.html Intelligent Design* * http://humanisteducation.com Continuum of Humanist Education * * http://www.secularstudents.org Secular Student Alliance * * http://www.darwinday.org Darwin Day Celebration * * HUMAN RIGHTS IMPERIALISM: NEW FACE OF OLD EXPLOITATION * GPG fingerprint = 2E7F 2D69 4B0B C8D5 07E3 09C3 5E8D C4B4 461B B771 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHl351Xo3EtEYbt3ERArPrAKC0eCHwkvDXcZD/+uONASK465lERgCgp4CS keVJy7NDuCypVbrjeFmvMEM= =pIvX -END PGP SIGNATURE- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : [computer-go] Is MC-UCT really scalable ... is a troll
Thanks. - Message d'origine De : Russell Wallace [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 18h07mn 27s Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll On Jan 23, 2008 3:44 AM, Don Dailey [EMAIL PROTECTED] wrote: This is still nonsense. UCT in actual real world PRACTICE responds dramatically to more hardware, how can you say it's not clear whether it's scalable in practice? In fairness, he didn't say that. What he said was that our belief regarding whether or not UCT scales in practice, should be based on tests on real hardware (which appear to give an answer in the affirmative), rather than on a mathematical proof of what happens in the limit as computer time tends to infinity (because what happens in the limit as time tends to infinity, doesn't necessarily have much bearing on what happens on real hardware; so tests are more informative). ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability study - how close to perfection?
On Wed, 23 Jan 2008, Don Dailey wrote: This bias was clear in 7x7 - I don't expect to see it here but I will check when there are enough games at the upper levels. I beg you ... add Mogo_14 to the study, please. Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Scalability problem of play-out policies
Joel Veness wrote: Hi Ivan, I like to view game tree search methods as a systematic ways to correct static evaluation errors. I don't find it surprising that UCT scales well with increasing time and space. I claim that the accuracy of the monte-carlo method increases as we get closer to the end of a game. UCT helps propagate monte-carlo evaluations from the best looking lines deep inside the tree. If the best line of play is deep enough and sampled well enough, then positions that might have caused problems for the monte-carlo evaluation will eventually be avoided. Remember that with UCT, no line of play is avoided forever, no matter what the monte-carlo evaluation says. Extra time and space just increases the chances of the UCT component correcting any errors in the monte-carlo evaluation, which is why I think it scales so well. I certainly think it is reasonable to suggest that certain flaws in a monte-carlo evaluation function could create scaling issues. This could happen if there ever reaches a point that a program is losing game after game due to the evaluation function not understanding some particular dynamic of the game quick enough to give the UCT search a chance of correcting the misconception. However, I actually don't think this to be the case in practice. Yes, you can entertain any unreasonable possibility but it's a waste of time. People get some idea in their head that in their mind they can see as happening, and perhaps can even construct some corner case that is possible or plausible, and then it can be endlessly debated but has nothing to do with anything actually happening. - Don I think that why the scaling results are so consistent and smooth is due to the imperfection that comes with using a monte-carlo evaluation function. We have to deal with stochastic noise, in addition to misconceptions due to the method. Since there are so many errors to correct (many of them small errors), any extra processing time provides ample opportunity to help the program get a better idea of the board situation and avoid that game losing blunder. In my opinion, this plays a big factor in creating these almost linear scaling results that we see regularly. Joel On Jan 23, 2008 4:16 PM, ivan dubois [EMAIL PROTECTED] wrote: Sorry, this may very well be nitpicking, but it is not nonsense. I just dont like when people are making illegitimate deductions, using the fact that the same word can have two distinct meanings. Anyway all this is just nitpicking from my part, I have to admit. What is not nitpicking however, is wether some play-out policy (wich might appear to be working well) can compromise the scalability of UCT at some point. I read that there seemed to be a problem with Fatman's scalability. I dont know what are the latest news about this, but I think you should at least consider the possibility that it may come from some persistent missconception from the play-out policy. After all, I may very well be right. After thinking a little about it, I came to the conclusion that there can be a scalability problem when : There is a bias in the MC evaluation AND there is no move to be made in the UCT part that can partialy correct the missconception of the MC evaluation. This happens each time there is a situation that just cannot be settled immediatly, but has to wait the end of the game. Now I think I can give you a clean example : The bent four in the corner shape : http://senseis.xmp.net/?BentFourInTheCornerIsDead Tell me if I am wrong, but I bet nor your program nor Mogo does scale at all on this situation. That means whatever computing power you can give to it, If i can create such a situation in my game against him, I will probably win. And notice that more computing power will not help Mogo to avoid this situation because it doesnt know it to be a problem. Tell me if I am wrong, but I think it is a scalability problem that puts a real limit to the strength it can reach in theory. But please, do not miss understand me, I am NOT saying that this is a crucial problem to MC that cannot be fixed. I am sure it CAN be fixed. I am just saying that currently MC programs do not scale infinitely, but I have no doubt that these problems will be corrected as soon as they become crucial to the playing strength. Ivan Message d'origine De : Don Dailey [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 4h44mn 17s Objet : Re: Re : Re : [computer-go] Is MC-UCT really scalable ... is a troll ivan dubois wrote: Thanks ! I think I agree with everything you said. After some reasoning, I changed my opinion about the practical scalability of Mogo. It does have some missconceptions about eyes, but as you said, it can be corrected by the UCT part. I tried to find a situation where the UCT part does not help until the situation
Re: [computer-go] scalability study - how close to perfection?
Just cool it. We intend to add 3 more mogo levels soon. - Don Christoph Birk wrote: On Wed, 23 Jan 2008, Don Dailey wrote: This bias was clear in 7x7 - I don't expect to see it here but I will check when there are enough games at the upper levels. I beg you ... add Mogo_14 to the study, please. Christoph ___ 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] scalability study - how close to perfection?
May I suggest a fundamental limit to the utility of this scalability study? We are comparing three programs to each other, IIRC - Fatman, Mogo, and Gnugo. All three are known to have certain odd little quirks. The two MC programs, in particular, are known to be deficient when addressing certain LD situations. They may continue to get better with respect to each other for some time yet. They will reach a sort of local optimum with respect to each other. At the end of the day, a halfway clever 9 kyu player will play the vital point on a bulky five, or induce the programs to create a square four, or some other common strategem, and the standard of play may be shown to have some serious gaps. The programs will be perfect or near genius level only against other programs. This is a variation of the problems faced by Sluggo -- if I recall correctly, it could give Gnugo a 6 or 7 stone handicap, which was a very impressive achievement - but it fell flat against the average human player. I think this study is useful - that's why I'm lending four cores - but I also think we should create some test cases and see whether more playouts will cause the programs to resolve these test cases properly, or not. When a group is provably dead, then it's contribution to the final estimation should be that of a 100% dead group, not 50% or 80%. I know this is difficult in the general case ( there's a paper demonstrating that it is NP-hard, if I recall correctly ), but let's try to test the 20-kyu and 10-kyu cases, at least. Otherwise, I suspect that it may be a very long time before these fairly common corner cases are handled correctly. Terry McIntyre [EMAIL PROTECTED] Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
By the way, my argument still applies when there are no outside liberties, because the eye filing itself is a long enough UCT trap (a sequence of moves that appears to be just like null moves). I gave a theoretical argument, but actualy it is not very surprising. Did you ever wonder why Mogo, being now so strong, could still exhibit so basic and stupid blind spots ? The explanation is very simple : Those blind spots reveal the fact that some aspects of its understanding do not scale as fast as the other aspects. Actualy for some aspects, it does not scale at all, from a practical point of view. Ivan - Message d'origine De : Michael Williams [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 20h38mn 32s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies ivan dubois wrote: I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). How are you arriving at this conclusion? It makes no sense to me. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
ivan dubois wrote: Hello, - Message d'origine De : Michael Williams [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 20h38mn 32s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies ivan dubois wrote: I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). How are you arriving at this conclusion? It makes no sense to me. Actually this is not true for this exact situation, but I think it is true if the black group has enough external liberties. Suppose it has 10 outside liberties, to make things very clear. For the simplicity of my argument, suppose also that the big eye is almost entirely filled with white stones (minus 1 liberty) Here is my reasoning : Starting from the root, there are some playouts where the black group dies, and other where it lives. Let us note X the proportion of playouts that end with the black group having been captured. Now is there any move A, starting from the root, that will change this ratio if you start the random playouts just after A ? I think clearly, the answer is no, do you agree with that ? The only relevant possible move would be to fill a liberty, but since all liberties will be filled anyway during the playouts, this will not change anything to the scenario. The only thing that matters is wether or not white plays first at the vital point every time the eye is reduced during the playouts. Using the same argument, there exists no sequence of less than 8 moves that can change the value of X. This means all these sequences of liberty filling will be considered to have exactly the same value than playing a null move. I think it implies that uct will never (of course in theory it will at some point but I say it would require absurd computing time) find the sequence that captures the group with 100% confidence, because this sequence begins with 8 apparently useless moves. You speak to imprecisely for me, sorry. When questioned, you reverse position. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: Re : Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
i.e., any case where discovering a particular position would require making illegal moves during that playout with respect to the move policy in place. so for instance, if the only way to discover the death of a group is to play inside one-point eyes, and there's a playout policy that says to never play inside one-point eyes, then the death of the relevant group will never be discovered, and will have zero estimated probability of ever occurring. not that it will have vanishingly small probability, but that it will have p=0. if this group is all that keeps two larger groups connected, for instance, then this is a problem for the understanding of the whole board situation. this has been beaten badly to death, however, so i'll take any responses off-list. s. - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 11:45:01 AM Subject: Re : Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hi, This is correct. Do you think there will be no playouts where the group dies ? I think there will be around 50% where the group dies. If you think this is not the case, please explain to me. Ivan - Message d'origine De : steve uurtamo [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 17h22mn 35s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies it will only assign it a positive probability of being dead if there are playouts where the group dies, right? s. - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 10:51:52 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, I agree that the current implementation of Mogo (from what I know about it) will not know for sure that the D17 black group is 100% dead. It will think that it is X% dead and stick to that estimation, whatever thinking time you give it. X is a constant that does not depend of thinking time (no scalability). However, and this can be surprising, I am not sure wether it is really a scalability killer for whole board play, because after all, it doesnt have to know with 100 % confidence the status of one group to play perfectly. - Message d'origine De : terry mcintyre [EMAIL PROTECTED] À : computer-go computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 16h24mn 53s Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Feed any MC-UCT program the position after White B1, at move 195, and ask the probability of a black win. Repeat until the program corrects its estimate. It would be interesting to determine just how many simulations are needed to solve this problem - which is obvious to double-digit kyu players. Terry McIntyre [EMAIL PROTECTED] - Original Message From: ivan dubois [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Wednesday, January 23, 2008 7:17:17 AM Subject: Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Hello, After thinking a bit more about it, I came to the conclusion that the so called Bent four in the corner shape, is not such a serious scalability killer (I like this term). Nor is the situation that appears in your game. Let me explain why : It would indeed be a scalability killer if Mogo was 100 % sure that some group is dead, when it is actually alive. However what happens is that it has some doubts about the situation. It may think for example it is 60 % alive and 40 % dead. Of course it would be better for him to know the reality, but having some persistent doubt on it is not that much detrimental. For example if he has perfect information about the rest of the board, he will play perfectly on the rest of the board. I propose a chalenge to this list : Find a real scalability issue with Mogo or any other actual UCT program. (And prove it) Ivan - Message d'origine De : Harald Korneliussen [EMAIL PROTECTED] À : computer-go@computer-go.org Envoyé le : Mercredi, 23 Janvier 2008, 15h31mn 20s Objet : [computer-go] Bent four in the corner was:Scalability problem of play-out policies Ivan Dubois mentioned the bent four in the corner shape as a scalability killer, a situation where more playouts doesn't help (much), because playouts systematically misevaluate it. As I understand it, it could be corrected in the tree, but this is very unlikely to happen until the very end of a game, by which time it may be too late (Mogo having worked the entire game for that solid 0.5 win, which turns out to be a solid loss instead because of the life-and-death misevaluation) I recalled a KGS game of Mogo I'd
Re : [computer-go] Bent four in the corner was:Scalability problem of play-out policies
I gave you a proof of what I am claiming, I really dont see what I can do more. Anyway we all now all this is just a waste of time for pleasure. People who are really working on a UCT engine (I dont anymore) will find solutions to these problems as soon as they become relevant to playing strength. You speak to imprecisely for me, sorry. When questioned, you reverse position. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] CGOS 9x9 is down
Maybe it's just a temporary thing, but I just happened to check and CGOS was down... I get lots of messages like the following: 22:43:00Server startup return code: 1 msg: couldn't open socket: connection refused 22:43:00Cannot connect to server. Will retry shortly ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain Gelly thesis in english
On Sun, 13 Jan 2008, Sylvain Gelly wrote: Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf That is NOT the latest version. Please at least let me put the latest version on my web site, it took me so long to correct it :). Where may we find the latest version? Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: [Cgos-developers] CGOS 9x9 is down
I am in the process of restarting it and you just happened to be there. There is still a bug in the server where occasionally the server will not realize a bot disconnected. In those cases it thinks they are still logged on and won't let them log back on. So until I find the bug, the server needs to be restarted occasionally.We should put this in bugzilla or whatever sourceforge uses to track bugs. I should be able to look into this next week, but I'm booked solid this week. - Don Jason House wrote: Maybe it's just a temporary thing, but I just happened to check and CGOS was down... I get lots of messages like the following: 22:43:00Server startup return code: 1 msg: couldn't open socket: connection refused 22:43:00Cannot connect to server. Will retry shortly - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Cgos-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/cgos-developers ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 MC improvement
On Jan 23, 2008 3:11 AM, Hiroshi Yamashita [EMAIL PROTECTED] wrote: 2. Change UCT exploration parameter exp_param = sqrt(2.0); uct = exp_param * sqrt( log(sum of all children playout) / (number of child playout) ); uct_value = (child winning rate) + uct; I changed exp_param sqrt(2.0) to sqrt(0.1). 2.0 to 0.1? That's a pretty big step. I did notice that libego worked better with lower constants than recommended by the formula -- in libego, the original UCB1 formula corresponds to an explore_rate coefficient of 8, but the default explore_rate coefficient of 1 seemed to be about the best. I am curious if any of those of you who have heavy-playout programs would find a benefit from the following modification: exp_param = sqrt(0.2); // sqrt(2) times the original parameter value. uct = exp_param * sqrt( log(sum of all children playout) * (child-win-rate-2) / (number of child playout) ); uct_value = (child winning rate) + uct; where child-win-rate-2 is defined as (#wins + 1) / (#wins + #losses + 2) If it happens that you do the equivalent of initializing #wins to 1 and #losses to 1 (in libego, setting the initial bias to 2), then you can just use your original (child winning rate) value. (W+1)/(W+L+2) is the mean of a beta(W+1,L+1) random variable, which is what you get when you start with a uniform(0,1) distribution and condition it by the observation of a W-L record. The explore parameter inside the square root is doubled so that when you have an average child-win-rate-2 value of 0.5, the formula returns the same value as before. (Using an initial bias of 2.0 seems like a good thing anyhow.) Adding this extra term seemed to help a bit (57% +/- 4.5% win rate over unmodified program) when the basic playouts were uniform. This change tends to make the formula stick with proven winners more than before, so you might need to increase the explore rate by a little more than sqrt(2). Your mileage may vary -- I'd also like to know if you try this change and find it unhelpful. The justification is that the standard deviation of a beta(1,21) is lower than the standard deviation of a beta(11,11) variable. The error term of a beta(21,1) is lower too, but applying the (L+1)/(W+L+2) term to the UCB1 formula can yield nonsensical results where when two moves have the same bias, the one with the worse win-loss record is assigned the higher UCB1 value. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] 19x19 MC improvement
On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote: I am curious if any of those of you who have heavy-playout programs would find a benefit from the following modification: exp_param = sqrt(0.2); // sqrt(2) times the original parameter value. uct = exp_param * sqrt( log(sum of all children playout) * (child-win-rate-2) / (number of child playout) ); uct_value = (child winning rate) + uct; where child-win-rate-2 is defined as (#wins + 1) / (#wins + #losses + 2) I'm surprised to see that this works as listed, because the math looks all wrong to me... I usually think of UCT as being based on the sample variance. It looks like you're using: sqrt(child_win_rate_2/number_child_playouts) Standard bernouli trials yield: sqrt(child_win_rate*(1-child_win_rate)/number_child_playouts) Beta distribution yields: sqrt(win_rate_2*(1-win_rate_2)/(number_child_playouts+3)) When using the full beta distribution theory, uct_value would be: child_win_rate_2 + uct Is it possible you have a typo in your uct calculation? If not, you're really favoring high win rates over low win rates. Or maybe with inversions of wins and losses between ply, you're favoring exploration of the less probable moves? I'd really be interested in hearing more about what you did! PS: I'm glad to see someone else using the beta distribution theory. I posted it to the mailing list long ago, but didn't think anyone found it very interesting/useful. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Sylvain Gelly thesis in english
http://www.lri.fr/~gelly/Publications.htm On 1/24/08, Christoph Birk [EMAIL PROTECTED] wrote: On Sun, 13 Jan 2008, Sylvain Gelly wrote: Google finds it: http://tao.lri.fr/Papers/thesesTAO/SylvainGellyThesis.pdf That is NOT the latest version. Please at least let me put the latest version on my web site, it took me so long to correct it :). Where may we find the latest version? Christoph ___ 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] scalability study - how close to perfection?
... it would explain the scaling curve flattening out. Though the curve can also be flattened/made-curvier by changing the base of the x-axis. Currently it is log-2. Proportional to actual playouts would make it appear flatter. No, that would make it appear more curved if I understand your terminology correctly. IN other words, it would be less of a straight line if it was not log(2) and instead was just number of play-outs. Hi Don, We're saying the same thing. By becoming flatter I mean the line on the chart is becoming closer to being parallel with the x-axis. (I.e. flat line means you've hit perfect play.) Darren ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: [Cgos-developers] CGOS 9x9 is down
Just allow any login to superceed any previous login. Don Dailey wrote: I am in the process of restarting it and you just happened to be there. There is still a bug in the server where occasionally the server will not realize a bot disconnected. In those cases it thinks they are still logged on and won't let them log back on. So until I find the bug, the server needs to be restarted occasionally.We should put this in bugzilla or whatever sourceforge uses to track bugs. I should be able to look into this next week, but I'm booked solid this week. - Don Jason House wrote: Maybe it's just a temporary thing, but I just happened to check and CGOS was down... I get lots of messages like the following: 22:43:00Server startup return code: 1 msg: couldn't open socket: connection refused 22:43:00Cannot connect to server. Will retry shortly - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Cgos-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/cgos-developers ___ 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/
