Hi Mark, It wasn't my intention to sound argumentative about this, I apologize for this.
Yes, I agree that the shorter mate sequence should be chosen and also that if all else is equal, the bigger win should be the course to follow. There is a misconception that MC favors winning by the smallest possible margin. This is NOT the case. It seems to happen a lot but only because it is often the case that a MC program prefers to make a loss absolutely impossible - even when you could probably win big with very little risk (but some.) I'm not saying that you have this misconception, but I know that many do. So far the empirical evidence says that it's hard to improve on this by considering the "magnitude" of the win. Several of us have tried this for one or both of these reasons: 1. Hopes that it makes the program a little better. 2. Some of us thinks this is "silly" behavior on the part of the program. I'm all for it if it makes the program stronger. One thing I tried is dynamically changing the komi once the program gets confident. This was an utter failure and it's not hard to see why. You are dynamically making it harder to win! This would sometimes cause it to ignore the winning strategy because you just told it that a win is not enough. This insight helped me understand why it's a problem in general, no matter how you do it. Whenever you tell it that it's better to win big than to win small, you are actually giving it conflicting goals. No matter how you look at it, to some extent you have to tell the computer that a win is not good enough. I don't think it's a silly idea however. An indirect goal COULD be better if it's more "implementable" in some sense. In computer chess you can't tell a chess program that only checkmate matters, your evaluation function must contain lot's of intermediate goals that substitute in some sense for the real goal. Winning material is such an intermediate goal. It's doesn't matter one bit whether you are down a queen if you checkmate the opponent, but it sure makes it easier to win if you have an extra queen. Nevertheless, the simple fact is that this hasn't proved to work in MC as of this time. I'm all for the idea if someone can make it work. - Don Mark Boon wrote: > Don, > > This has taken me some time to formulate an answer. Mainly because you > are making so many assumption about what I understand or imagine and > what not. It makes for a confused discussion and I didn't feel like > getting into arguments like "no, that's not what I meant etc." > > Let me therefore change the discussion a bit to see if this will make > things more clear. Consider a chess-playing program with an unorthodox > search method. When playing a human after while it announces > check-mate in thirty-four moves. Yet the human can clearly see it's > check-mate in four. Ah, one could say, but the computer is 100% > confident winning either way so it doesn't care which one it chooses. > It doesn't matter whether a human thinks mate in four is more beautiful. > > Now it so happens that with chess we're pretty confident that when a > chess-program announces check-mate that it is in fact correct. But > what if there could be a sliver of doubt? Maybe the program has no > doubt, but the programmer might. Bugs happen. Wouldn't you say it's > better to choose the shorter mate sequence? Regardless of whether > humans may find it more beautiful? > > It's with this example in mind when I say winning with more points is > better. A MC Go program may show 100% confidence in winning, but all > that means is that all playouts ended up with a win. But we know that > it could still be wrong, and with a much higher likelyhood than the > chess program described above. > > Maybe you're right and a bigger win should only be favoured if the MC > playouts show the same probability of winning. It seems to me the most > conservative approach that should be followed at least. Somehow I feel > there's a bit more to be gained though by giving the size of the win > slightly more weight than that. But I'm also willing to accept that > that may just be an illusion. > > Mark > > _______________________________________________ > 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/
