TalkChess.com

[david nash]

I thought about this - the problem of searching for tree lines that can transpose must occur in Hippo style positions, with many transposable lines.
without captures or moving the same piece twice there must be [ply ! ] number of lines to search, this becomes very time consuming I guess.

Maybe there is a good way of removing the hash key as a way of finding transpositions in the build phase, however so far I think the hash key is the best way.

The problem of hash collision can at least be solved by walking the tree of the game that the original collided hash was from ...

After transpositions are merged, if the table is walked in variation first form, (breadth first), to find the terminal nodes for the indexes to the game list, then there could be a problem with double transpositions.

If double transpositions are ignored, then the tree (graph) can be walked to the ends to store data ranges of the list of game indexes. Then the re-indexed game list can have a sortable column for the data ranged selection. It might be a bit time consuming to work out when lines transpose twice every time, however when a variation turns into the mainline the lists would occur twice ... I suppose it would have to simply write into a set data structure.

I don't know how much space this fantasy structure takes ...