On Mon, May 10, 2010 at 10:47:41AM -1000, Mark Boon wrote:
> On Mon, May 10, 2010 at 10:33 AM, Don Dailey <[email protected]> wrote:
> > There is no need for this unless it is a speed optimization. You can find
> > any child by generating the hash key of each child. It seems ridiculous to
> > me to store an average of at least 100 pointers per node.
>
> It's possible of course I have misunderstood how hash-tables work or
> are implemented. How, from a position in the hash-table, do you get to
> the next position with the best win-rate? I doubt the hash-key is
> generated on-the-fly as that would be very expensive since it would
> entail the administration of making a full move, counting (some form
> of) liberties and removing captives. So I always assumed they are
> stored, probably as hash-keys, in the node. But then I see no
> difference between a pointer or a hash-key. Just a different name for
> the same thing.
I have never implemented a hash-table but I would have expected the
hashes of all successive moves to be part of the parent node. However,
that would make descending extremely cache-unfriendly. And I don't see
how would transpositions be handled if winrates would be part of the
parent as well.
--
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
