Another perft(7) challenge position

[Luis Babboni]

3016055832 saids Soberango.
Time: 2907.1 segs!!

[bob]

But the issue is that once a month has zero impact on the tree search result. Once a day has zero impact. Even once a minute has zero impact. Verified with two different chess programs. One false match per million nodes searched had no effect.

So adding 64 bits and doubling the computational cost only reduces something that is already zero...

Your argument would be stronger if only scores or bounds are stored.

But when also storing moves, using 128 bit signatures means no need for running move sanity tests on each move retrieval. I'll bet that the time saved by skipping sanity testing is much more than the time spent on shoving around an extra eight bytes here and there.

When my programs went from 64 bit to 128 bit signatures, I tossed the move sanity test code. But I remember that it was non-trivial because of special case moves and that even a fast path through would hit several conditionals:

1) Origin square must have STM man.
2) Destination square must be vacant or have non-STM man.
3) CanMoveTo(origin, destination) to be proven.

Number three also needs an make/unmake test if subsequent logic expects legal-only moves.

That's all bug magnet code. The only simple way to code a sanity test is to generate all the moves and see if one matches.

I'll stick with 128 bit signatures instead. I suppose that could be cut down to 96 bits, going from a 350 million year MTBF to a 60,000 year MTBF.

If you tossed it with 128 bits, why not toss it with 64 bits. Collisions are still extremely rare, and positions where an illegal move will break something are even rarer. Yet BOTH still have the potential for an occasional crash. Good software development policy dictates that a program should NEVER crash, period. I think the best-case so far is compressing a chess board into 168 bits. You are 2/3 of the way there with 128. By going the full enchilada, you have zero probability of a crash.

As far as sanity testing goes, all you need is to test the cases that would cause a crash/problem, such as castling without a king and rook on the right squares. Chess programs make so many positional errors in their evaluations already, not to mention mistakes in reductions, forward pruning, etc. Worrying about an error that won't crash is a tempest in a teapot sort of deal. Forget about worrying about errors that will produce a wrong answer once in a zillion times, it won't affect the root move chosen at all.