On Dec 4, 2007 1:42 AM, Petri Pitkanen <[EMAIL PROTECTED]> wrote: > > There is something that the latest Monte Carlo programs have in common > > with the best chess programs - and seems to be the right way to > > structure a game tree search. Your selectivity should be > > progressive. In order to do this correctly you must re-visit nodes > > many times. Chess programs do it iteratively and Monte Carlo UCT type > > programs do it "best first" fashion. So the decision to prune any given > > move is a decision that is considered many times in the course of a > > search - each time taking advantage of additional information. > > > > I think Monte-Carlo is more attempting solve a different issue > altogether. Sure it is a search tree buyt main problem is the > evaluation function. Currently we do not know any good way to evaluate > the situation on go board until the game is at very late stages. And I > think - not that I could support this with any testing - that most of > the current evaluation function would not play better if they had > deeper global search and actually may play worse with wider global > search. > The way I see it, Monte-Carlo *is* an evaluation function. Run a few thousand simulations from a given position and the fraction of them that you win is an indication of how good the position was to begin with. I can't imagine why you would say that deeper/wider global search would hurt. The only reason not to search deeper or wider (I assume by that you mean "less selectively") is lack of resources.
Relatively speaking chess eval of adding piece values together and > doing nothing else is far closer to optimal evaluation function that > what is currently available in Go. Adding piece values together is just a crude starting point in chess. It is true that there isn't an obvious candidate in go to play a similar role, but it's not like you can get a grandmaster-level program by counting beans. > Also there is not much published information evaluation functions in > Go. Obviously a go programming is a business and giving out such > information does not make sense. Best publicly available thingy is > GnuGo and it does not even have one. This was true of chess too, and there is more money to be made in computer chess, so my guess is that people are more secretive there. Any simplistic Go-veal would probably result in very bad choices in > early stages of game - like playing on second row without proper > reason. Any simplistic evaluation function in pretty much any game will result in horribly bad moves when there are no obvious tactical gains to be had. Try a closed position in chess, for example. > So selective search is part of eval. What? That doesn't follow at all. I'm not even sure what it means. > And this shortcoming is > pretty obvious in MC programs. when they play on full sized board they > make extremely funny moves and so good result against humans only in > ultra-blitz conditions - humans scale better I guess. Poor performance of current programs doesn't mean anything. People in the 80s could have made similar arguments saying that alpha-beta searchers with a simple evaluation function that considers material and positional values only cannot possibly be the right approach, as evidenced by their funny moves and their poor results against humans. It turns out that an evolution of that approach on much faster hardware plays better than humans. Álvaro.
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
