Crikey -- it worked!
Incorporating moves into the tree with a transposition table, I'm
still getting 10,000 games per second with the dual cores. The games
are still purely random -- UCT is tomorrow's job.
I went ahead and (*shudder*) created the TwinNode objects on the fly,
rather than maintaining a pool of them, since they're much rarer than
true Nodes. It looks like I create about one transposition in every
ten runs using purely random games, but I expect this will drop off
precipitously under UCT. If I'm wrong, I can always add a node pool.
Orego is hugely faster and uses an order of magnitude less memory
than it did 24 hours ago. Thanks, everyone!
Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/
On Dec 7, 2006, at 10:07 PM, Anders Kierulf wrote:
I was also hoping to use my DAG as a transposition table,
so I could use the Zobrist hash of the current position
to find where the child node would be if it existed. If
the space was already occupied (by a node at the right
depth), I would have a transposition.
If each "node" might really require several nodes, this
trick won't work. Oh, well. I guess I was trying to kill
too many birds with the same stone.
I'm solving that by using a separate hash table that points to the
base node
for each position. But it seems like you should be able to use the DAG
directly as a transposition table too, with the twin nodes
implemented as an
overflow list.
Anders Kierulf
www.smartgo.com
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
