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?
Seems you are doing something inconsistently. If the hash hit makes it fail high in the aspiration window, that same hash hit should still make it fail high with the open window, right?
The fail high is based on the hash entry from the previous search. But the re-search doesn't have the depth to see the mate - which results in a fail low.
Maybe it's normal. It's certainly ugly.
One way around it would be to only do a hash cut-off if the age of the entry is current. So "old" hash entries are used for move ordering only.
[pgn]
[Event "Who can make the most ridiculously long mate puzzle"]
[Site "?"]
[Date "1000 BC"]
[Round "?"]
[White "Mate in 30"]
[Black "?"]
[Result "*"]
[SetUp "1"]
[FEN "5n2/B3K3/2p2Np1/4k3/7P/3bN1P1/2Prn1P1/1q6 w - -"]
Play up to and including 15...Kd5 and let your engine think until it finds 16. Nf6+ and mate in 15. The move forward two moves and see if it find Nf7+ mate in 14.
Steve Maughan wrote:The fail high is based on the hash entry from the previous search. But the re-search doesn't have the depth to see the mate - which results in a fail low.
That still doesn't explain it. If the re-search does not have the depth to see the mate, the aspirated search should not have had the depth to see it either. The re-search is not any deeper than the aspirated search, right? And a hash hit that has sufficient depth for one should have sufficient depth for the other.
Or is the problem that by the time the re-search is done, the hash entry for the mate is overwritten? That would suggest there is something seriously wrong in your replacement algorithm.
If the previous search found the mate in 15 (Nf6+), the path and mate score will hopefully be stored in the hash table. This means on the next search it plays Nf7+ with a zero width window and gets an immediate fail-high cutoff due to the mate value stored in the hash table. It then opens the search window and tries to find the mate. However, at the lower ply it does not have the depth to see it and so fails low.
Note I do not do hash cutoffs at PV_NODES.
I think I have concluded it's just an artifact of Maverick's search.
Steve Maughan wrote:The fail high is based on the hash entry from the previous search. But the re-search doesn't have the depth to see the mate - which results in a fail low.
That still doesn't explain it. If the re-search does not have the depth to see the mate, the aspirated search should not have had the depth to see it either. The re-search is not any deeper than the aspirated search, right? And a hash hit that has sufficient depth for one should have sufficient depth for the other.
I gave a similar comment to Natale in his long thread a while ago, but he still thinks that everything works well and the behaviour of his engine which he initially found suspicious were expected. I still do not believe that, and tend to believe the same as you. But without the source code it is hard to prove that there is an error.
