After looking at your message I'm not sure you understand how I set this up.
On Thu, 2007-02-08 at 01:00 +0100, Unknown wrote: > > to binary search the file on the parent position key, > > collect all of these records together (making sure there is a > > legal move which leads to the cannonical response key) and then > > You are not clear here. > Is there only a one-move-step between key and resp ? > Why not store the move in the first place ? (instead of the resulting > hash) The book has 1 record per playable move. If there are 4 responses to some position in the book, there will be 4 records, one for each possible response. Those 4 keys will have the same "key" field which is a "cannonical key" of the position. But they will have separate child keys (resp for resulting position) which are also cannonical. From some actual position it's trivial to convert the cannonical child keys to actual moves using the cannoical hash. The "count" is just a priority system which right now happens to corespond to how many times the book searcher wanted to play the move in question (and since I set an arbitrary limit of 8 searches, all the moves for a given position would total 8 if all the lookups have been completed.) Doing 8 searches is time-consuming, but I really prefer a book that has a LOT of variety. If I decide that the book stuff is really useful, I will probably convert it to use a sqlite3 database which is quite nice and easy to use and manage, I might even place search data such as the score and number of nodes searched in such a database. - Don _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
