Re: [computer-go] BOINC
On 29/10/2007, Ian Preston [EMAIL PROTECTED] wrote: G'day guys, I'm involved in the development of a very powerful and flexible grid software, which we plan to release in January. It is all java based. http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download it yet and the website is out of date) One of the things I'd like to do on it, once it is finished, is some kind of attack on Go. I've messed around trying to genetically generate algorithms to play go. However this has had to go on the back burner for the moment. The brief attempt I made had no way of storing data between games (I ran out of time) and the best algorithm it came up with was a purely random algorithm... :-) our group is also the one that is doing JPC - http://www-jpc.physics.ox.ac.uk/ I'd love to hear about anyone else distributed attacks on Go. It would be great to see a java port of GoTools by Thomas Wolf[1], which is probably the kind of thing that most naturally lends itself to distributed attacks. Does anyone know whether GoTools is under active development? The webpages were last updated in 2001... cheers stuart [1] http://www.qmw.ac.uk/~ugah006/gotools/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] CGOS
Christoph Birk wrote: It appears as if both CGOS servers crashed ... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ cgos.lri.fr is still working, but the web page is not updated anymore. You can follow games with cgosview. Rémi ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] BOINC
milestone 1: All network-nodes compute pure Monte-Carlo (no search tree) scores for the possible moves, the scores are combined centrally to pick the move. It's easy, it will wring out the system, and the bandwidth is low. The playing performance will always be poor because this algorithm doesn't scale well. milestone 2: Each network-node builds its own tree using UCT, but information is only combined at the root. This version will play much better because each node is smarter. The bandwidth will be higher. I can only guess at the scaling behavior, but this milestone might be the 80% solution. milestone 3: Information from the search-nodes is shared between network-nodes, but only for search-nodes close to the root of the tree. Sounds innocent enough. You just limit the shared nodes to the first couple of plys. But it's a trap that will suck you in: best scaling behavior requires too much communication-but what if you made each Monte-Carlo simulation smarter...? Why not make each computer specialize in a certain branch of the tree? That way the (implicit) combination of the trees of all the computers could grow very large. Of course some central intelligence would need to allocate resources to different branches dynamically, so it would be more difficult to implement. In these three milestones, the different computers would do a lot of overlapping work with the deeper nodes, if I understood them correctly. -- Tapani Raiko, [EMAIL PROTECTED], +358 50 5225750 http://www.cis.hut.fi/praiko/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] BOINC
On Tue, 30 Oct 2007, Stuart A. Yeates wrote: On 29/10/2007, Ian Preston [EMAIL PROTECTED] wrote: G'day guys, I'm involved in the development of a very powerful and flexible grid software, which we plan to release in January. It is all java based. http://www-nereus.physics.ox.ac.uk/ (bear in mind you can't download it yet and the website is out of date) One of the things I'd like to do on it, once it is finished, is some kind of attack on Go. I've messed around trying to genetically generate algorithms to play go. However this has had to go on the back burner for the moment. The brief attempt I made had no way of storing data between games (I ran out of time) and the best algorithm it came up with was a purely random algorithm... :-) our group is also the one that is doing JPC - http://www-jpc.physics.ox.ac.uk/ I'd love to hear about anyone else distributed attacks on Go. It would be great to see a java port of GoTools by Thomas Wolf[1], which is probably the kind of thing that most naturally lends itself to distributed attacks. Does anyone know whether GoTools is under active development? The webpages were last updated in 2001... There is a newer web page http://lie.math.brocku.ca/gotools/ with links to some recent publications for checking solutions of life and death problems and a link to http://lie.math.brocku.ca/gotools/applet.html which is a Java based online service. A standalone Java interface was developed on and off and will hopefully be ready in the next months. Thomas Wolf cheers stuart [1] http://www.qmw.ac.uk/~ugah006/gotools/ ___ 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] Where is Mogo?
Le lundi 29 octobre 2007, Don Dailey a écrit : I don't see Mogo on the server?Where is Mogo? However CrazyStone is there to represent the Monte Carlo programs and seems to be doing a very good job indeed! CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is doing absurdly well for far, winning almost every game it plays. - Don According to http://gemma.ujf.cas.cz/~cieply/GO/statev.html this seems to say CS-8-26-2CPU is near 4 stones stronger than GNU (even if 6/7 games is not statistically very robust estimation) I m waiting to see how CS_H3 do ... Alain ___ 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] Handicap vs Elo
Le lundi 29 octobre 2007, Don Dailey a écrit : I don't see Mogo on the server?Where is Mogo? However CrazyStone is there to represent the Monte Carlo programs and seems to be doing a very good job indeed! CS-8-26-2CPU http://www.lri.fr/%7Eteytaud/cross/CS-8-26-2CPU.html is doing absurdly well for far, winning almost every game it plays. - Don According to http://gemma.ujf.cas.cz/~cieply/GO/statev.html this seems to say CS-8-26-2CPU is near 4 stones stronger than GNU (even if 6/7 games is not statistically very robust estimation) I m waiting to see how CS_H3 do ... Alain ___ 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] Definition for monte carlo
There has been a lot of talk about monte carlo and while I have the jist not sure exactly what it is? Would someone explain it? What I've read online is just to play a bunch of random games and pick the best one. Is there now real evaluation between the games or sorted method for generating movements? -Josh ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Definition for monte carlo
On Tue, Oct 30, 2007 at 12:43:35PM -0400, Joshua Shriver wrote: There has been a lot of talk about monte carlo and while I have the jist not sure exactly what it is? Would someone explain it? Here is my (amateurish) understanding: Evaluation of a go position is very difficult. Monte Carlo (MC) is one way to shortcircuit this. The idea is to play the game to the bitter end, very quickly, and badly, on the assumption that if the position favours white, then white is likely to win, even if both players play equally bad quality moves. Taken to the extreme, they play pure random games. This can be done very quickly, and doing it many times gives some sort of measure of how good the position is. Now all is left for a pure MC player is to try every legal move, evaluate them with enough MC playouts, and choose the one that is most likely to win. This works surprisingly well, although there are some drawbacks. Evaluating positions this way prefers safe, solid groups. And in the end game, when the result is decided, the programs play unnatural moves, since all moves lead to the same result - the resulting score is usually not considered, so to the program it is the same if it wins by 0.5 points or the whole board... On its own MC is not all too strong, but it solves the evaluation problem. This can be included in some tree-search based programs, most commonly UCT or similar. And the results are surprisingly good. Lukasz Lew has written a simple C library that makes it easy to experiment with the thing. Google on 'Lew libEGO' and you should find him. - Heikki P.S. If any of the above is not right, I am sure the better informed people will rush in to correct me. I welcome that! -- 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] BOINC
On 10/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: -Original Message- From: Jason House [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Mon, 29 Oct 2007 3:00 pm Subject: Re: [computer-go] BOINC On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: milestone 1: All network-nodes compute pure Monte-Carlo (no search tree) scores for the possible moves, thescores are combined centrally to pick the move. It's easy, it will wring out the system, and the bandwidth is low. The playing performance will always be poor because this algorithm doesn't scale well. It scales, reasonably, but there's a maximum total work to do before any extra becomes useless. Both of our statements are so vague that I can't tell if we agree or disagree. :) Here's what I meant. The consensus is that Monte-Carlo with UCT converges in the limit, as time and memory approach infinity, while Monte-Carlo by itself does not. In practice, Monte-Carlo by itself plateaus out at around 5K playouts/move. Don's scalability study tested Monte-Carlo with UCT out past 1 Million playouts/move and found no sign of a plateau. So if a network of 1000 computers played pure Monte-Carlo go, I believe the playing strength would still be weak. Not so for UCT. I think we're in agreement. I didn't know about the 5k limit, but that's essentially what I was thinking. Having 1 computer do 5k sims is pretty quick already. Having 1000 computers doing 5 playouts each is just insanity. The overhead would probably make it take as long (or longer) as 1 computer doing all of it. This is of course true only for pure monte carlo or other 1-ply variants. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] BOINC
It would be very difficult to put 1000 computers to work on a big network to produce a single instance of a strong player. There are way too many interactions - it's difficult to split the work up in a reasonable fashion. It's probably possible, but would require a lot of study. There are certain compromises that effect the playing strength of a single processor program but might be very good trade-offs for a such a beast. - Don Jason House wrote: On 10/30/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -Original Message- From: Jason House [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: computer-go computer-go@computer-go.org mailto:computer-go@computer-go.org Sent: Mon, 29 Oct 2007 3:00 pm Subject: Re: [computer-go] BOINC On 10/29/07, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: milestone 1: All network-nodes compute pure Monte-Carlo (no search tree) scores for the possible moves, thescores are combined centrally to pick the move. It's easy, it will wring out the system, and the bandwidth is low. The playing performance will always be poor because this algorithm doesn't scale well. It scales, reasonably, but there's a maximum total work to do before any extra becomes useless. Both of our statements are so vague that I can't tell if we agree or disagree. :) Here's what I meant. The consensus is that Monte-Carlo with UCT converges in the limit, as time and memory approach infinity, while Monte-Carlo by itself does not. In practice, Monte-Carlo by itself plateaus out at around 5K playouts/move. Don's scalability study tested Monte-Carlo with UCT out past 1 Million playouts/move and found no sign of a plateau. So if a network of 1000 computers played pure Monte-Carlo go, I believe the playing strength would still be weak. Not so for UCT. I think we're in agreement. I didn't know about the 5k limit, but that's essentially what I was thinking. Having 1 computer do 5k sims is pretty quick already. Having 1000 computers doing 5 playouts each is just insanity. The overhead would probably make it take as long (or longer) as 1 computer doing all of it. This is of course true only for pure monte carlo or other 1-ply variants. ___ 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] Definition for monte carlo
Heikki's answer is close. I would think it important to add that MC is a statistical sampling algorithm, so the attempt is to simplify the difficult job of evaluating a board state by sampling a large number of random continuations, with the assumption that if enough samples are checked, you will have some idea of the likely outcome starting at that board. Any one continuation is of virtually no value, it is only the statistics that are meaningful. By substituting board state plus one more move for board state you get an estimated value for the move you are adding to the board as long as you start the random sequence many times with that particular move. Now my personal bias: This method is extremely valuable and accurate in physics because we have a very solid theory for determining the distributions in thermal or quantum systems. This means that we do not simulate every possibility with equal probability, but use a bias that is specified by equations we trust and that have proved to work. The problem in Go is that we have no such theory yet, so, we end up with hand-tuned rules and biases created by other means, such as a UCT tree, to slowly and somewhat inefficiently (compared with having the right bias from an equation) move from what is being called pure MC (but really means uniform random) sampling towards a bias better for Go. Cheers, David On 30, Oct 2007, at 9:58 AM, Heikki Levanto wrote: On Tue, Oct 30, 2007 at 12:43:35PM -0400, Joshua Shriver wrote: There has been a lot of talk about monte carlo and while I have the jist not sure exactly what it is? Would someone explain it? Here is my (amateurish) understanding: Evaluation of a go position is very difficult. Monte Carlo (MC) is one way to shortcircuit this. The idea is to play the game to the bitter end, very quickly, and badly, on the assumption that if the position favours white, then white is likely to win, even if both players play equally bad quality moves. Taken to the extreme, they play pure random games. This can be done very quickly, and doing it many times gives some sort of measure of how good the position is. Now all is left for a pure MC player is to try every legal move, evaluate them with enough MC playouts, and choose the one that is most likely to win. This works surprisingly well, although there are some drawbacks. Evaluating positions this way prefers safe, solid groups. And in the end game, when the result is decided, the programs play unnatural moves, since all moves lead to the same result - the resulting score is usually not considered, so to the program it is the same if it wins by 0.5 points or the whole board... On its own MC is not all too strong, but it solves the evaluation problem. This can be included in some tree-search based programs, most commonly UCT or similar. And the results are surprisingly good. Lukasz Lew has written a simple C library that makes it easy to experiment with the thing. Google on 'Lew libEGO' and you should find him. - Heikki P.S. If any of the above is not right, I am sure the better informed people will rush in to correct me. I welcome that! -- 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Definition for monte carlo
When an MC bot is ahead, it'll play safe moves that help guarantee a coast to victory (many times by 1/2 point). I am surprised by how often an MC bot wins by exactly 0.5 point.It's almost as if it is converging to a 0.5 victory. One way to look at this is that an MC program is all about consolidating just the amount of territory it needs to win.It will never go for a big win and doesn't associate extra goodness to a bigger win.It's much easier to win small so I guess it makes sense that really tiny victories are very common in MC programs. - Don Jason House wrote: On 10/30/07, *Heikki Levanto* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: This works surprisingly well, although there are some drawbacks. Evaluating positions this way prefers safe, solid groups. And in the end game, when the result is decided, the programs play unnatural moves, since all moves lead to the same result - the resulting score is usually not considered, so to the program it is the same if it wins by 0.5 points or the whole board... I don't think MC evaluation favors stable groups. It's really a function of the perceived chances of winning. When behind, it'll play bold moves since it's the only real way to win. An MC bot that is behind in endgame (even if by 1/2 point) plays so wildly, it frequently loses all of its stones! When an MC bot is ahead, it'll play safe moves that help guarantee a coast to victory (many times by 1/2 point). P.S. If any of the above is not right, I am sure the better informed people will rush in to correct me. I welcome that! I thought it was a great summary. My only caveat is up above. ___ 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] Definition for monte carlo
On Tue, Oct 30, 2007 at 01:33:07PM -0400, Jason House wrote: I don't think MC evaluation favors stable groups. I guess I didn't really say what I meant here. MC evaluation sees weaknesses in groups that can be killed by random play, even if they are safe enough in the eyes of human players. For example a group with one long eye, 4 points long, is considered unconditionally alive, but a MC evaluator sees some chance in killing it, because the defending side plays pure random, and is as likely to shorten it to 3-space eye as to split it in two independent eyes. In real games this may not make much of a difference, but it is possible to construct positions that get evaluated wrong by MC. Perhaps a clever program might even take advantage of such... It's really a function of the perceived chances of winning. When behind, it'll play bold moves since it's the only real way to win. An MC bot that is behind in endgame (even if by 1/2 point) plays so wildly, it frequently loses all of its stones! When an MC bot is ahead, it'll play safe moves that help guarantee a coast to victory (many times by 1/2 point). I think you are reading a bit too much intention into its play. When the game is already decided, it makes no difference where to play. So a pure MC program will end up playing totally random. If it is winning, it will happily let parts of a group die, as long as that does not change the result. If behind, it will not try to collect small points here and there, but just play where ever - often leading to death and destruction among its own groups. -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] Definition for monte carlo
On 10/30/07, Heikki Levanto [EMAIL PROTECTED] wrote: It's really a function of the perceived chances of winning. When behind, it'll play bold moves since it's the only real way to win. An MC bot that is behind in endgame (even if by 1/2 point) plays so wildly, it frequently loses all of its stones! When an MC bot is ahead, it'll play safe moves that help guarantee a coast to victory (many times by 1/2 point). I think you are reading a bit too much intention into its play. When the game is already decided, it makes no difference where to play. So a pure MC program will end up playing totally random. If it is winning, it will happily let parts of a group die, as long as that does not change the result. If behind, it will not try to collect small points here and there, but just play where ever - often leading to death and destruction among its own groups. In a decided game, you're right. When the game is not decided, it's an important consideration to take into account. Let's say you have to decide between gently containing your enemy or going for an all-out kill. Certainly, containment will give more reliable results. If that reliable result is a victory, it's the right move. If the result would be a loss, it's time to go for a kill. This type of decision (maybe in less extreme cases) is a common decision criteria for players stronger than me. As a moderately strong human, I play with a fixed strategy. I accept a fixed level of risk for all my groups and territory, and rarely waiver from that. In my relatively conservative strategy, I've coasted to a loss by 10 point or less more times than I care to count. This concept is quite foreign to a reasonable MC player. Similarly, I've been in won games and gotten bitten by a tesuji by the opponent. If I had been just a bit safer in my play, I could have had a comfortable win. Similarly, reasonable MC bots solidify the core to win rather than try to keep everything. A lot of times, when these factors have a big impact on the MC play (as a deviation from human-like play), humans consider it to be blunders by the MC bot. They really aren't, it just feels unnatural. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] BOINC
On Tue, 30 Oct 2007, Jason House wrote: I think we're in agreement. I didn't know about the 5k limit, but that's essentially what I was thinking. The 5k limit is only true for heavy playouts (Don wrote that for 'Anchorman'). light playout don't plateau that early but are intrinsically weaker, eg. myCtest-10k: 1054 ELO myCtest-50k: 1340 ELO Using AMAF there is vitually no difference between 10k and 50k. myCtest-10k-AMAF: 1480 ELO -50k-AMAF: 1470 ELO Christoph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Definition for monte carlo
If you're ahead and go for a bigger win, generally you're just risking more to gain more when you don't need more. there is *absolutely* no advantage from a game-theoretical point of view to try to win by more than 0.5 points. and in practice, it's generally not a great idea to try to win by any more than you absolutely have to. this goes toward the game-goal of the first person to really explain the game to me, who said that both sides should strive for a balanced game. a 0.5 pt. game is a perfectly played game. which is not exactly the western view of winning. and which, i agree, gives far too much credit to MC players, since they roughly emulate this line of play purely by accident. however, most people won't go so far as to ignore an unreasonable invasion where you *let your opponent live inside your territory* even if it wouldn't add up to enough to cause them to lose the game. it's pride, or something. if you can prove* that you can stop an invasion with no risk to yourself, people will generally play to stop it, although to be fair, if you knew you didn't have to, by ignoring it you are not treating it like a huge source of ko threats for your opponent, which is a good thing. they might not really be ko threats, if they don't add up to enough for you to lose if you win the ko fight by ignoring them. which is part of the tricky nature of a ko. measuring the size of the threat. one way that people will often play that i think has no basis in an attempt to win, but which is simply human nature, is to occasionally fight a ko fight to the bitter end regardless of whether it will affect the outcome of the game. you'll see games that are decided by 10-15 points with 30 moves worth of ko threats to determine who gets the extra fraction of a point. this may be under the assumption that, if i win the fight, i definitely won't lose the game, but if i lose the fight, maybe there's something that i didn't see that could cause me to lose the game or it could just be kiai. but neither seem game-theoretically justifiable. for some reason this gets great cheers from the audience, whereas a computer player sacrificing 10 stones unnecessarily seems horrifying. even with very, very good computer players, i think that with sufficiently tight time controls we will always see this happen, since it's an easy decision to make, and much better than losing on time. s. *i.e. that any unconditionally alive group with a border of single-colored stones should be able to prevent any freshly invading stones from living. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Definition for monte carlo
Hi Steve, steve uurtamo wrote: If you're ahead and go for a bigger win, generally you're just risking more to gain more when you don't need more. there is *absolutely* no advantage from a game-theoretical point of view to try to win by more than 0.5 points. and in practice, it's generally not a great idea to try to win by any more than you absolutely have to. this goes toward the game-goal of the first person to really explain the game to me, who said that both sides should strive for a balanced game. a 0.5 pt. game is a perfectly played game. which is not exactly the western view of winning. and which, i agree, gives far too much credit to MC players, since they roughly emulate this line of play purely by accident. I don't agree with that.There is no accident here, MC really only cares about winning and has no ego about winning big.They don't go out of their way to win small either if that's what you mean.Unless you are saying that you should strive to go out of your way to win small so that the game is balanced then I don't know what you are talking about. Because they are not perfect players they don't always do this perfectly, so you could say they are not balanced in this sense, but that applies to all imperfect players including the very best human players. They may strive to play balanced but they don't quite succeed either. however, most people won't go so far as to ignore an unreasonable invasion where you *let your opponent live inside your territory* even if it wouldn't add up to enough to cause them to lose the game. it's pride, or something. if you can prove* that you can stop an invasion with no risk to yourself, people will generally play to stop it, but of course MC programs don't care. They might stop it by accident but not on purpose. Is this what you mean by unbalanced? Monte Carlo programs don't have a specific policy to lose stones on purpose just to keep the score balanced or close. They simply don't care either way. although to be fair, if you knew you didn't have to, by ignoring it you are not treating it like a huge source of ko threats for your opponent, which is a good thing. they might not really be ko threats, if they don't add up to enough for you to lose if you win the ko fight by ignoring them. which is part of the tricky nature of a ko. measuring the size of the threat. one way that people will often play that i think has no basis in an attempt to win, but which is simply human nature, is to occasionally fight a ko fight to the bitter end regardless of whether it will affect the outcome of the game. you'll see games that are decided by 10-15 points with 30 moves worth of ko threats to determine who gets the extra fraction of a point. this may be under the assumption that, if i win the fight, i definitely won't lose the game, but if i lose the fight, maybe there's something that i didn't see that could cause me to lose the game or it could just be kiai. but neither seem game-theoretically justifiable. I agree. I think in some sense it dishonors players to do this. It's very western isn't it?I say that it dishonors a player to do this because the assumption is that it shows honor to give your very best effort to win (it would show disrespect to throw the game) but after having secured the win trying to do more is like kicking a man when he is down, as if to humiliate him. for some reason this gets great cheers from the audience, whereas a computer player sacrificing 10 stones unnecessarily seems horrifying. even with very, very good computer players, i think that with sufficiently tight time controls we will always see this happen, since it's an easy decision to make, and much better than losing on time. s. *i.e. that any unconditionally alive group with a border of single-colored stones should be able to prevent any freshly invading stones from living. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Definition for monte carlo
Heikki Levanto wrote: On Tue, Oct 30, 2007 at 12:55:21PM -0700, steve uurtamo wrote: If you're ahead and go for a bigger win, generally you're just risking more to gain more when you don't need more. there is *absolutely* no advantage from a game-theoretical point of view to try to win by more than 0.5 points. and in practice, it's generally not a great idea to try to win by any more than you absolutely have to. On the other hand, it is equally pointless to throw out points in order to win by exactly 0.5 points. Especially if doing so increases your risk of miscalculation etc. But MC programs really are reasonable in this sense. If there is the SLIGHTEST doubts in their silicon minds about their winning chances, they will not throw out points that could save the game. There is this hidden assumption that MC programs are weakened because of not maximizing their territory (due to miscalculation) but the truth of the matter is that they are as pragmatic as you can get.WE are the ones irrational about it. We are the ones that feel we need to win a few more points just in case for good measure. An MC will win a few more points for good measure if it increases the probability of winning the game. We may see it miscalculate in this regard, but we can't fault the logic, only the miscalculation. Attempts to change the behavior to our more irrational point of view has always resulted in weakened play. This is part of the reason they are so good and probably a weakness of most if not all conventional GO programs.This is behavior that I can imagine would be very difficult to emulate in a conventional program, although there might be some attempts to do so. - Don I bet most of us have played a game where we thought things were nicely under control, only to have the opponent to play a surprising tesuji and gain a few points in the endgame. If one was pointedly aiming at a 0.5 point victory, such a tesuji could loose the game. If one was avoiding risks, but among equal moves, choosing the one that maximizes the score, such risk would be smaller. Of course this does not apply if one has confidence in having the game perfectly well analysed, and will know how the game will end. Such finesse is seldomly seen in kyu-level human players. And computer programs are not quite that perfect either... - H ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
