The hash entry obviously has the following
int64 hash
int addrNext; // if needing a mainline
int addrVariation;
then for each move the game is merged by putting all variations found in a linked list of hash entries, so for a game list stored in sparse format
Code: Select all
1.e4 e5 2.Nf3 Nc6 3.Bc4 // game 1
3.Bb5 // game 2
3.Nc3 // game 3
I don't know what to do about terminal nodes or nodes with only 1 game passing through - perhaps the index of the game can be written and merged iff another game scores a hit ?
I also tried to create a DAWG (direct acyclic word graph) for the FEN's to try to create perfect hashing ... the fen can already be compressed to 5 bit chars, then I got a 15 mb to 10 mb compression for the Fen list to DAWG file sizes.
If anyone has tried this disk tree concept I'd be interested to hear about how to compress the tree and whether its worth storing sparse move lists, or whether to just use SQL and a compressed move list, with maybe a gui button to call CQL for position searches.