On May 11, 2010, at 6:35 AM, David Fotland wrote: > It is quite memory hungry since near the leaves there are many positions > with very few active children. On 9x9 I let a few playouts go through a > move before expanding it, and that gives me plenty of memory. I ship with a > default of 300 MB reserved for the hash table, and that's enough.
So that confirms more or less how I thought hash-tables were implemented (although others may still use different methods of course). Using rather more memory than a tree implementation. But I see the advantages in terms of efficiency. What I do in the tree is when I first expand a node I stick in a small place-holder that just has the move and the RAVE values (and a bit more) but no child information. Only when a node gets selected because it has the best RAVE score does it get replaced by a full node. On average less than 10% of the nodes get replaced by a full node. You could probably do something similar with a hash-table. But the implementation might get a little more complex. Mark _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
