[computer-go] KO in Hashtable-UCT?

[Chrilly]

>> >
>> I have serious problems with KO. UCT-Suzie plays generally strong, but 
>> makes
>> terrible blunders in KO-positions. So far I do not even understand the
>> problem. Could you describe it more detailed?
>> I had also some serious SuperKO problems. UCT-Suzie was very "clever" to
>> find SuperKOs. We do not check for SuperKO in Alpha-Beta. The search is 
>> not
>> deep enough. Ignoring SuperKO in UCT is for a Hashtable version deadly.
>> GameStack-Overflow.
>>
>> Chrilly
>
>
> So does your hash function consider all previous board states (for
> superKo)?  If so, how?  I can think of one way, but I don't use it
> since I have a tree that handles the allowable moves independent of
> the hashtable.
>
When going down a variation the Hash and other Board-State Information like 
e.g. the KO-Point are stored on a stack. Starting from the current Top of 
Stack the detection goes down and search for the same hash-key and Ko-Point. 
Its the "Repeated Position" Detection method of chess. The Gamestack-Pointer 
is decremented by 2, one can stop, when a non-capturing move is done (in 
chess its the other way round). One can start 4 Plies from the top of stack. 
Due to the stoping criterion one has to check only a few entries (most of 
the time none).
If a SuperKO occurs, the position is evaluated by the Material-Balance. 
BlackCaptures - WhiteCaptures + Komi. Probably a better way is to ignore the 
result. But I assumed that SuperKO is a rare event and the result has no 
significant impact on the search-tree.
Maybe there is something wrong with this approach and the Ko-Problems I have 
a related to this simple SuperKO handling. I noticed several times that a 
direct transformation of chess methods has some subtle flaws.

Chrilly

 _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/