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...Zach Wegner wrote: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.bob wrote: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...
This costs a few instructions total, and there are no other side effects. Middle game positions would work exactly the same as before.
Semi-Path Dependent Hashing: a semi-useless idea.
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL