On Sun, May 9, 2010 at 10:45 PM, Mark Boon <[email protected]> wrote:
> > On May 9, 2010, at 12:46 PM, Don Dailey wrote: > > > I think you are the one missing something. Once you are at a node, > it's hard to determine how many parents that node has and where they are. > In other words this node could be the child node of more than one parent. > Of course you know from the context of the search who ONE of the parents > is, but other parent nodes will be different (although very similar) > positions. > > Hmmm, I think you're (also) missing it. Please re-read carefully what I > wrote before. I'll give it one more try to see if it's clearer. > > It's easy to determine how many 'parents' a node has because I keep a > hash-table with lists of nodes that have the same hash-key and each of those > nodes knows its parent. So for every node I simply lookup the list to know > what the parents are. I put 'parents' in quotes, because they are not really > parents of the current node. They are the parents of equivalent nodes. > > And tell me what part you think is wrong, so I can try to explain better. > I'm sure I have it right. (Famous last words, hehe.) > Ok, I now understand now how this would make multiple parent lookup possible, but it seems terribly wasteful of space. Are you just assuming that memory is no limitation? So you are basically using the tree based data structure which is wasteful of space and supplementing it with a hash table to give you transposition information. You are trying to get the best of both worlds by accepting the downside of both methods too. Don > > Mark > > _______________________________________________ > Computer-go mailing list > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
