Mating but not smoothly

[casey]

My mate score is 10000. When analyzing a position, the scores jump like bellow:

ply score
18 1118
19 9975
20 9973
21 9975
22 9977
23 9977

The last score 9977 is correct.

Questions:
1) Is it normal when searching deeper, the engine may have better mating scores? (I mean why my engine can't find the best mate 9977 at ply 19 but ply 22 - the best mate should have a lower search tree than the longer ones but my engine found longer ones before the best one).

I see that some other engines have the same behavior but I am not really convenient about that. Need your opinions.

2) At ply 20, the mating score (9973) is lower than previous one (9975). Is it reasonable / explainable or is there a bug on my search?

My engine has hash table, null move, extensions of 1 depth when in-check or 1 reply. No check in qsearch, no any kind of razoring / pruning.

Thanks all for helps.

[hgm]

This is normal. Your mate score 9977 corresponds to mate in 23 ply (I suppose). So there is no guarantee you will see it before the search reaches a depth of 23 ply. Any mate you find before that is essentially a matter of luck, and usually not the fastest. To find them at all you are usually dependent on hash grafts. As you only get those by searching moves in the wrong order, they tend to disappear in the next teration, where you search the best move first (and thus do not get the same graft anymore).

[bob]

My mate score is 10000. When analyzing a position, the scores jump like bellow:

ply score
18 1118
19 9975
20 9973
21 9975
22 9977
23 9977

The last score 9977 is correct.

Questions:
1) Is it normal when searching deeper, the engine may have better mating scores? (I mean why my engine can't find the best mate 9977 at ply 19 but ply 22 - the best mate should have a lower search tree than the longer ones but my engine found longer ones before the best one).

I see that some other engines have the same behavior but I am not really convenient about that. Need your opinions.

2) At ply 20, the mating score (9973) is lower than previous one (9975). Is it reasonable / explainable or is there a bug on my search?

My engine has hash table, null move, extensions of 1 depth when in-check or 1 reply. No check in qsearch, no any kind of razoring / pruning.

Thanks all for helps.

One reason is extensions, and this is a well-known problem. If you find a mate in 10 where every move is a check, you can find that at a relatively shallow nominal search depth since every checking move gets extended. But suppose there is a forced mate in 7, where the first 6 moves are not checks. They won't be extended, so it takes a deeper depth to discover that mate.

Whether that is your issue or not is not clear, however...

[casey]

In case the mate scores jump up and down, how do we know which ones are correct? Thanks.

[hgm]

You won't, unless you reach the depth where the mate is within the horizon. And then it should stop jumping up and down.

But the scores should all be upper limits to the true DTM.