Don Dailey: <[EMAIL PROTECTED]>: > > >Hideki Kato wrote: >> I'd like to give here an example to make things clear. >> >> The conditions are: >> 1) Using digitizing scheme that maps real score to [0,1] (or [-1,1]) >> so that the program cannot distinguish losing/winning by 0.5 or 10.5 >> pt at all. >> 2) Playouts include some foolish moves (usually with low >> but not zero probability), not to connect large groups in atari >> position for example, due to hold its randomness. >> 3) The position is at early endgame where there are no moves that >> gain greater than 2 pt, for example, in perfect play. >> 4) Black is behind by 0.5 pt. >> >> The playouts may return winning but gambling move (perhaps with low >> probability) under above conditions, especialy in case of the number >> of playouts is small which is usually true on 19x19, and UCT will >> choose it. >> >> The question is, which is better to keep 0.5 pt behind or to play >> gambling moves (here I mean such moves that B will lose many pts if W >> will answer correctly) with expecting W's (stupid) mistakes? >> >> >The assumption is that you suddenly cannot trust MC to do what it does >best even though you did for the entire game up until this point. MC >of course will choose the "gambling" move. The whole concept of MC >is to do what is most likely to produce a win. > >We should think twice before asking it to choose the moves that produces >the more sure loss. We are the ones that have a bias about this, not >the MC programs.
Whatever the 'concept' of MC is, I just will improve its weakness by any means. MC is just a method, IMHO, to evaluate a position better than to use a static function. # I'm just an engineer :). >> In addition to above, there is one more issue to consider. If the >> playout has a systematic error, nakade for example, it's not good to >> keep 0.5 pt ahead. Having more margin is clearly better. >> >I believe nakade is a strawman. There are lots of things MC does >better and lot's of things it does less well. You can always find >positions that are hard or easy for your program to solve, but it isn't >intrinsic to this issue. I don't think you should weaken this >concept of playing for the best winning chances for the very few >positions where MC programs take longer to resolve the endgame and there >is a slight chance that it will win if it just happens to be enough to >cover the exact situation. Because this is no solution - it is at best >a patch and would only work in some cases. If I could do something >that didn't hurt the program in other ways, but might help certain >positions once in a while, I would go for it. I've been in game >programming a long time - if you have a problem with certain types of >positions you really want a pointed solution that has little or no >impact on other positions. You don't want to be going back and forth >fixing things up but you want to solve the problem as correctly as >possible the first time. I'll call this principle, "every solution >has a side effect" but this is a pretty bad side effect. (I can't >tell you how many times I "fixed" something in my chess program with >some evaluation change only to find that I broke many other things at >the same time.) Although I'm afraid my English skill is enough to understand such a long paragraph correctly (shorter is better :), I believe it's just a choice. Some are good at developing an essential solution but not all. As I know I'm worse at that, I just do what I can. It was developped for the First UEC Cup that features Japanese rules which count seki differently so that all MC programs need to have some margin. Rémi introduced a fixed margin by changing komi for Crazy Stone and I've developed a dynamic one. Do you say we have to wait until we will develop an essential solution? -Hideki >- Don > > > >> The idea of floating komi helps above two. I'd like to emphasize that >> I know it's not a universal solution. As it seems, however, very hard >> to solve nakade problem, it could be a pracitical solution. >> >> -Hideki >> -- >> [EMAIL PROTECTED] (Kato) >> _______________________________________________ >> computer-go mailing list >> [email protected] >> http://www.computer-go.org/mailman/listinfo/computer-go/ >> >> >_______________________________________________ >computer-go mailing list >[email protected] >http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
