Semi-Path Dependent Hashing: a semi-useless idea.

[bob]

3. This one position does not make me uninterested. The very idea of not using available hash information is what I don't like. Solving a very infrequent problem by making a change that affects each and every other move negatively is my issue with this idea... not to mention the cost involved in a second path signature...

But once again you seem to overlook that a certain implementation of this idea solves your fifty-move problem in a more correct way (i.e. not invalidating some valid entries that you would) and without the cost of running through the entire hash table.

This costs a few instructions total, and there are no other side effects. Middle game positions would work exactly the same as before.

Fine, but that cost is not trivial. The hash signature is not free. The idea might become workable in some way, I am not sure. It is food for thought, but I hope it is not the "end of the story" because I do _not_ want to give up on transpositions that occur in the _current_ iteration, with different paths, which is the unfortunate side-effect of your change. My fix does not have that cost. And in endgames like fine #70, that cost is far from insignificant. Opening/middlegame positions might not be affected as much, but since I have not tried it, I can't say one way or the other. But the cost of computation is not insignificant, and the cost of requiring path matching in the current iteration is a killer for endgames...