[computer-go] Former Deep Blue Research working on Go

[Rémi Coulom]

Rémi Coulom wrote:
> Andrés Domínguez wrote:
>> 2007/10/10, Don Dailey <drdailey at cox.net>:
>>  
>>> 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