I see Sven too had just replied, but I only briefly browse through his post without raking my brain too much.
I think I now understand what's happening.xmas79 wrote: Let me explain it more precisely... We already know that original position is mate in 11, and there's no doubt about it. So suppose a ply 22 search returned already that mate score (32000-21 = 31979). Let's suppose I do not stop iterating at ply 22 (as I found the minimal mate and I could stop searching), and keep iterating. Let's suppose we are starting iteration at depth 26. Is it possible to reach the original position at ply different than 0 and get a hash hit? Well, yes, by a long sequence of moves that leads to the same position after exactly 26 plies. We can suppose it can happen because TT entries can be overwritten, PV sometimes is truncated, move order at this point can be completely random and I have no evaluation that drives search towards best moves (and that's another story...)
In this case we are at ply=26 and can get a hash hit (draft condition is OK and hash signature is OK) returning a score back that is 31979. At this point, we will adjust the score by subtracting 26 plies from 31979 ---> 31953 ---> which is a mate in 47 plies even if horizon is at ply 26. So I have just replaced my "mate in 21 plies" TT entry with one that says "mate in 47 plies"... And this entry can be in turn be hit and get replaced by another "mate in 85 plies" and so on...
My intuition says this is happening here, but I can't explain better than this, and I have no other means to explain this behaviour... Maybe what I wrote is completely wrong, but I need something that points my eyes on the (very subdole) bug (if any), because if this is not a "standard" behaviour, well I really don't have idea of what's happening here and of what I'm really doing....
Believe me! Read my lips! There is nothing wrong with your search. Everything's fine and your
search is behaving "normally". Your description is also all correct.
My guess (hopefully correct) is that you did not implement what most of us do - returning a draw score of zero on the first repetition.
1) There is the draw rule for a three-fold repetition. Most program don't wait till three repetition. After a move is executed, there is a loop to detect a first repetition; mine is like this :
Code: Select all
makemove(*move, side);
if (currstack->fifty < 100) {
/* a rep move is valid as it repeats a valid move.
* 1st possible repetition is each side 2 moves/fifty >= 4 */
for (i = 4; i <= currstack->fifty; i += 2) {
if (currstack->hash ^ (currstack - i)->hash);
else {
x = DRAW0;/* 1st repetiton scored as a draw == 0 */
pv[ply + 1][0] = 0;
goto SET_BEST;
}
}
} else {
x = DRAW0;/* fifty draw */
pv[ply + 1][0] = 0;
goto SET_BEST;
}
When your search at root did the depth 26 iteration, and at ply 26 at a leaf node, repeats the same position as that at the root. TT probe gives mate-in-26. Before returning with a fail high, your "always overwrite" TT scheme would rehashed that position as mate-in-47 - it is all proper. What it means is that from the leaf node at ply 26, you could checkmate by (traveling to the moon and back!) by taking a path that repeats (do many backmoves, ...) many of the positions earlier along the line playing until you reach the root-position - that's 26 half-moves! Now you go for the kill- take another 22 half-moves and announce - Checkmate. That's a mate-in-47.
Sorry that I did not read your earlier posts very carefully and miss the point.
Best Regards,
Rasjid.