On 7/10/07, chrilly <[EMAIL PROTECTED]> wrote:
I have no finished a plain vanilla 9x9 Suzie-UCT Version. The UCT-tree is stored in a Hashtable. I am interested who else uses this approach. The reason for using a hashtable was: I was too lazy to implement an explicit tree. At least at 9x9 I have no problem with memory size. In fact there are 2 hashtables, one for the Alpha-Beta and one for the UCT-Version. With the default parameters each version uses 160 MB.
I'm not there yet with my rewrite, but I plan to be there again soon. There is immense repetition in positions as the search gets deeper, and it just doesn't make sense to not do hash tables. A chessprogrammer in Go-Land, part X:
I interpreted SuperKo as repetition of position (which seems to be correct, although Stefan Mertin told me, there are numerous versions of SuperKo). I used the Nimzo/Hydra code to detect this. But there is a - not a very subtle - difference between Go and Chess. A move which generates a repetition of position is in Chess legal, in Go it is'nt. But I assumed its legal and had quite complicated and buggy code to handle this case. I did not know how to evaluate it. It came not to my mind, that its just an illegal move and one only has to generate the nextbest one. Stefan Mertin told me the difference several times, but it did not help, only the advice of Peter Woitke, just delete this stupid code, was the right instruction level.
I'd be interested in hearing how people handle graph history interaction issues. A move from a specific board position may be legal or illegal depending on how that position was obtained. I use the simple ko position as part of the hash key, and generally ignore positional superko and situational superko when doing my search. That seems to make sense since the superko situations are pretty rare while ko is fairly common. I've considered putting in some simplistic superko avoidance such as tracking a bit more history of captures in the hash key, but I haven't convinced myself that it's worth it yet. I think I have three hash values for every position - black stone, white stone, and simple ko. I don't need to disallow ko by color since it only ever applies to one color at a time (the color to move).
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
