Rémi Coulom wrote:
Andrés Domínguez wrote:
2007/10/10, Don Dailey <[EMAIL PROTECTED]>:
Andrés,
You are right about null move of course. The assumption that other
moves are >= to the value of a pass is much stronger in GO than in
Chess, yet ironically it's not as effective in Go.
That was what i was trying to say. Pass is one of the worst moves
(except final) is good for null-move on Go. Of course you have
reduced depth, probably bad with alpha-beta with a bad evaluation
function, but looks interesting with UCT reducing the number of
simulations and increasing the % value. I don't use UCT, so I
haven't tried it.
Andrés
Hi,
UCT does no alpha-beta pruning, so null-move pruning cannot be used.
Rémi
Hi again,
I did not read your reply carefuly before answering, sorry. I still
don't believe your approach could work. You would waste a lot of
simulations searching a bad move, and it would be extremely difficult to
determine how much the % value should be increased. In alpha-beta tree
search, you only need to determine that one move is better than another,
regardless of the difference in value. In UCT, it is very important to
also determine how much better one move is. I cannot see any reasonable
approach to determine how much the null move is worse than the others.
Depending on very subtle details of the position, it could be a lot or
very little.
Regarding the question of null move in Go, I remember that some
programmers who tried it in alpha-beta programs did not manage to make
it work (Peter MacKenzie comes to mind, maybe others). As Don wrote, the
main problem of null move is the depth reduction. It hides long-term
threats that the evaluation function might not be able to evaluate.
Rémi
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
