Steve Maughan wrote:Note I do not do hash cutoffs at PV_NODES.
Ah, so that is the inconsistency then.
Then you just see here how not doing cutoffs at PV nodes hurts you. You fail to profit from the extra depth you could have had by hitting upon an overdeep hash entry.
There are also other ways search instability can occur, so you should always be prepared for the re-search of a fail high to fail low.
Please give a try with 8mb tt size and with 1gb tt size.I bet you'll get different results.Also be sure you have a complete pv to the mate.i now store pv in another place instead of tt and i'm fully able to retrieve it. That gave more different (and better) results. I didnt tested my original position as i'm out.more on monday. But i'm absolutely sure this is perfectly normal,and has everything to do with the luck of overwriting the wrong/right entry in the tt.pv on another place helps aearch instability issues.
Maybe it is an inconsistency,but in this case the CUT offs occur on fail high part of the tt probe.I disabled CUT offs in exact entries completely and the instabity never went away.only when removing CUT offs on the fail high part
What could you possibly do? You have a deep draft tt entry that says mate in no more than X. But it is a bound. You can't search deeply enough to resolve the mate, so you get a non-mate score. There's nothing that can be done, unless you want to disallow the bound causing a cutoff. May as well throw the TT out then...
Actually there are things you can do. If the problem is that the TT entry with the mate score is just a lower bound, so that it is no good for a hash cutof in a PV node even if you do allow those, you could make an exception for mate scores. Mate scores are usually reliable bounds; if a search turns up a mate score as lower bound it really must have seen a way to force a mate in the reported number of moves. These are not things that could be imagined due to prunings that are only allowed with null-windows etc. The only issue is that there could be a faster mate.
So if your TT gives you a mate-score as lower bound, but you need an exact score, so you re-search, and the re-search cannot find a mate, you would do better to return the TT bound than to return the score from the re-search. The error in this score will surely be far smaller than when you would return a non-mate score.
This also holds when you do not allow hash cuts in PV nodes and have an exact entry. You do the search there mainly as a kludge to recover the PV from the TT, and the fact that this might replace the score from over-deep hits by the less-reliable score from the search at nominal depth is an unwanted side effect. In case of a mate score you could decide to use the TT score anyway, after you searched the move at nominal depth to recover the PV. Normally there would be an entire trail of entries leading to the mate in the TT, so in fact only the first miss would return a non-mate score, which in its parent would be overruled by the TT mate score obtained at higer depth. And from there it would propagate in the normal way to the root.
It's illustrated in the diagram below. In this case Maverick has found a mate in 14 from a previous search. So when it starts searching Nf7 fails high on the first few ply due to the stored value in the hash table. When the search window is increased Maverick must find the mate, which it doesn't due to lack of depth. So it fails low. This results in the nasty fail-high followed by fail-low pattern. I know it's not a big issue but is there any way to stop this?
Thanks,
Steve
It is common if you use singular extensions based on windows around the score. After changing the score to the checkmated score, SE is not triggered because every move fall inside the window.
I took your advice and added hash cutoffs to PV nodes. If the score is exact and falls between alpha and beta I fill the PV with the moves from the hash table. It works well (and doesn't look ugly).
Hi Steve,
allowing hash cutoffs in PV nodes will never solve your instability. Your instability will only "change". I'm absolutely sure these kind of things are pretty common and normal.
The fact is that the "normal" behaviour is to NOT see mate before the nominal depth. BUT, engine will see mate scores before nominal search depth because it will get hash hits all over the tree during search saying "mate in 3", "mate in 4", "mated in 7" etc... and these hash entries are ALL lower/upper bounds types scores. So your engine has the ability to cut-off on non-PV nodes, but it cannot take any kind of cut in PV nodes, as the score required is EXACT, and in your hashtable there is no single entry that says "hey that's a mate in 16 moves, and that's an exact score!", as this would be the mate you're searching for!!
I told you to be sure you have a PV to the mate, as if you don't (and you don't), your engine will research on a window that is (alpha,+INF), and all the cut-offs "available" when searching with a window that is (alpha, +INF-1000 lets say) are no more profitable, so engine relies only on its search capabilities, and as it has no the "right" depth, will fail to see the mate and report the best score it can see with the search only - a draw.
I actually do have an EXACT mate score in the hash. This is the PV from the previous search. It makes sense to use this information. So now what I do is to take the PV node cutoff and fill the PV with info from the hash table. It seems to work well.
