On Wed, Jul 6, 2011 at 12:51 AM, CHAN Cheung <[email protected]> wrote: > Hi, > > I am a newbie to this list and hope the following comments help. > > Considering the opening and midgame, with MC evaluation the winrates using > either maximization method are similar because there are a lot of unsettle > variations thus the winrates in both cases should not have the cutoff > issue (term explained in the following). > > Cutoff issue occurs in endgame when the many moves have winrate around 0 > or 1 so that the engine cannot distinguish good yose moves from those with > less yose values with the winrate maximization method. In this case, human > feels that the engine plays badly and continues to play in the case that > the person should actually resign due to the large point difference. This > is concerning the user experience and the overall strength of engine. This > affects the strength of the engine due to the following reason. >
It has only a very minor strength impact because when you get the point where the engine is playing like this, it is VERY sure of the win and almost always IS a win. Otherwise it would not be playing like that. The primary reason this slightly degrades the strength is when something happens the program does not properly handle, such as seki or nakade or bizaare issues with the definition of an eye. In those cases it would have helped to have a bigger lead. In other words without fixing the real problem we can get sometimes get the win anyway. If the goal is to improve the user experience that is perfectly valid and should be done. I don't think anyone objects to that and I certainly do not. However this should not be confused with how to improve the playing strength of the program, there are much more productive ways to proceed, such as fixing the actual problems that cause these glitches where a won game is lost. This issue is usually presented as a way to make the program play stronger but there is very little "low hanging fruit" to be had in this regard. If you can do it really well it's possible you will get a slightly stronger program. > > Consider we have a winning game in the endgame but the engine keeps > playing bad moves (with winrate ~ 1) and losing points. Finally the > opponents find the optimal sequence that can turn loss to win (recall that > MCTS sometimes finds only suboptimal moves). The engine cannot distinguish > good moves from MANY bad moves since all these moves have winrate ~ 1. > This is bad and lowers the strength of MCTS at endgame. We should avoid > this problem by applying the point difference maximization scheme in this > case, and ONLY in this case. For other cases, like having only a few (<= > 3) moves with winrate ~ 1 or losing (winrate < 0.5), MCTS can do its job > well that we do not need modification. > > One other thing concerning user experience is that in the VERY LATE > endgame (say yose values of all moves < 5), when the engine is facing an > experienced (human dan) player and it is losing with a small point > difference (e.g. < 4). In this case, since the opponent is not a dum so it > is useless to play crazy moves like latest MCTS engines do. In the eyes of > experienced human players the winrate is exactly zero for the engine, > though the bot gives a non-zero value. In this case, in order to enhance > the user experience of these experience human players, we may apply the > point difference scheme as well, just to finish the yose "nicely" instead > of abrupt resignation. Of course, this lowers the winrate of the game, > especially to weak opponents like GNUGo, but I think the dan players are > happy to have this feature. > > Regards, > C Chan > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
