TT scores better than mate in 1 or worse than checkmate ,how

[MahmoudUthman]

How does This happen when using the usual score adjustment as below :
Probe:

Code: Select all

if (entry.Score >= Value_Mate_In_Max_Ply) entry.Score -= ply;
		else if &#40;entry.Score <= Value_Mated_In_Max_Ply&#41; entry.Score += ply;

Store:

Code: Select all

if (Score >= Value_Mate_In_Max_Ply) Score += ply;
		else if &#40;Score <= Value_Mated_In_Max_Ply&#41; Score -= ply;

, and is it really necessary to have a safety range between mate in one and +infinity and also between checkmated and -infinity equal in length to the greatest possible search ply, and does using Mate distance pruning remove this necessity "if it exist" ?

[MahmoudUthman]

Any one ?

[Guenther]

Any one :( ?

Don't forget it's the worst time in the year to ask such a question.
(between Xmas and NewYear) Surely there will be answers after
January 1st.

[hgm]

How does This happen when using the usual score adjustment as below :

I am not sure what you are asking, in particular what 'this' refers to, and what it has to do with the (truncated) title of the thread.

I have no experience with the adjustment you show the code for. The only thing better than mate in 1 is King capture. If your engine does not allow that, the score obviously should not occur in the TT. If the constant Value_Mated_In_Max_Ply differs enough from the mated-in-1 score (i.e. more than 'ply' can ever be), the code you give should not be able to produce such a score.

I don't know why you refer to Steven Edwards' post. He does not do the adjustment you show here either. He just stores the mate-in-N score in the TT for positions that are mate in N.

[MahmoudUthman]

How does This happen when using the usual score adjustment as below :

I am not sure what you are asking, in particular what 'this' refers to, and what it has to do with the (truncated) title of the thread.

I have no experience with the adjustment you show the code for. The only thing better than mate in 1 is King capture. If your engine does not allow that, the score obviously should not occur in the TT. If the constant Value_Mated_In_Max_Ply differs enough from the mated-in-1 score (i.e. more than 'ply' can ever be), the code you give should not be able to produce such a score.

I don't know why you refer to Steven Edwards' post. He does not do the adjustment you show here either. He just stores the mate-in-N score in the TT for positions that are mate in N.

I meant this

Note: It is possible to get scores better than mate in one or worse than checkmated, so there has to be a safety range between mate in one and +infinity and also between checkmated and -infinity. This safety margin length has to be at least as long as the greatest possible search ply.

I don't allow king capture , but with the adjustment I mentioned above I see scores better than +-Mate , even though the distance between Value_Mated_In_Max_Ply and mated-in-1 = MaxPly and this happens even when the ply is still relatively small compared to MaxPly!

I referred to Steven's post since I though that he was talking about this issue in reply to Marco's post above

[hgm]

I don't think that remark by Steven refers to scores in the TT. Just to the limits alpha and beta of the search window. Usually these are 32-bit integers, while scores are limited to fit in 16 bits for TT-entry compactness. So the ultimate score of a position can be 32,767, while alpha and beta can safely run upto 2G.

Like I said, I am unfamiliar with this method of adjusting TT mate scores. But it seems to me it should be impossible to get a score > mate-in-1 with the code you show. You add'ply' to the score, but in the nodeyou do that, 'ply' must be smaller than the level where you found that mate (or the score could not have propagated to there), and set the score to Mate minus ply.

[MahmoudUthman]

I don't think that remark by Steven refers to scores in the TT. Just to the limits alpha and beta of the search window. Usually these are 32-bit integers, while scores are limited to fit in 16 bits for TT-entry compactness. So the ultimate score of a position can be 32,767, while alpha and beta can safely run upto 2G.

Like I said, I am unfamiliar with this method of adjusting TT mate scores. But it seems to me it should be impossible to get a score > mate-in-1 with the code you show. You add'ply' to the score, but in the nodeyou do that, 'ply' must be smaller than the level where you found that mate (or the score could not have propagated to there), and set the score to Mate minus ply.

I think I found the cause although I'm not sure , for example at the end of the search when all moves fail low , we store alpha in the tt for the position but if alpha >MateInMaxPly then after adjusting it could exceed MateIn0 !

by the way I added a check in discoCheck's -"a relatively strong engine"-

Code: Select all

score_to_tt

function and it exhibit the same behavior (some scores after adjusting exceed +-matein0) , but I didn't see the same behavior in SF !

*In my engine so far none of those that exceeded mateScore after adjusting were exact.

[Sven]

I don't think that remark by Steven refers to scores in the TT. Just to the limits alpha and beta of the search window. Usually these are 32-bit integers, while scores are limited to fit in 16 bits for TT-entry compactness. So the ultimate score of a position can be 32,767, while alpha and beta can safely run upto 2G.

Like I said, I am unfamiliar with this method of adjusting TT mate scores. But it seems to me it should be impossible to get a score > mate-in-1 with the code you show. You add'ply' to the score, but in the nodeyou do that, 'ply' must be smaller than the level where you found that mate (or the score could not have propagated to there), and set the score to Mate minus ply.

I think I found the cause although I'm not sure , for example at the end of the search when all moves fail low , we store alpha in the tt for the position but if alpha >MateInMaxPly then after adjusting it could exceed MateIn0 !

by the way I added a check in discoCheck's -"a relatively strong engine"-

Code: Select all

score_to_tt

function and it exhibit the same behavior (some scores after adjusting exceed +-matein0) , but I didn't see the same behavior in SF !

*In my engine so far none of those that exceeded mateScore after adjusting were exact.

The situation you describe sounds very artificial. It *may* happen but with normal behaviour it *should not* happen. In my view you only start searching with a window that has alpha="some positive mate score" if you have already found a forced mate in the previous iteration. But then the next iteration should not fail low on that mate score.

But even if we assume that it happens then storing a "too high" value as an upper bound, or a "too low" value as a lower bound, should not do any harm to your search, it is just useless information in the TT, like "the score is +mate_in_0 + 100 or lower" or "the score is -mate_in_0 - 100 or higher", which shouldn't lead to a TT cutoff.

So I'm not sure whether the finding you describe already explains the wrong behaviour of your engine. I still have the impression that there is some real bug in the code, e.g. something like mixing "upper bound" and "lower bound" when storing or retrieving.

[MahmoudUthman]

I don't think that remark by Steven refers to scores in the TT. Just to the limits alpha and beta of the search window. Usually these are 32-bit integers, while scores are limited to fit in 16 bits for TT-entry compactness. So the ultimate score of a position can be 32,767, while alpha and beta can safely run upto 2G.

Like I said, I am unfamiliar with this method of adjusting TT mate scores. But it seems to me it should be impossible to get a score > mate-in-1 with the code you show. You add'ply' to the score, but in the nodeyou do that, 'ply' must be smaller than the level where you found that mate (or the score could not have propagated to there), and set the score to Mate minus ply.

I think I found the cause although I'm not sure , for example at the end of the search when all moves fail low , we store alpha in the tt for the position but if alpha >MateInMaxPly then after adjusting it could exceed MateIn0 !

by the way I added a check in discoCheck's -"a relatively strong engine"-

Code: Select all

score_to_tt

function and it exhibit the same behavior (some scores after adjusting exceed +-matein0) , but I didn't see the same behavior in SF !

*In my engine so far none of those that exceeded mateScore after adjusting were exact.

The situation you describe sounds very artificial. It *may* happen but with normal behaviour it *should not* happen. In my view you only start searching with a window that has alpha="some positive mate score" if you have already found a forced mate in the previous iteration. But then the next iteration should not fail low on that mate score.

But even if we assume that it happens then storing a "too high" value as an upper bound, or a "too low" value as a lower bound, should not do any harm to your search, it is just useless information in the TT, like "the score is +mate_in_0 + 100 or lower" or "the score is -mate_in_0 - 100 or higher", which shouldn't lead to a TT cutoff.

So I'm not sure whether the finding you describe already explains the wrong behaviour of your engine. I still have the impression that there is some real bug in the code, e.g. something like mixing "upper bound" and "lower bound" when storing or retrieving.

I think the cause of the wrong behavior is this coupled with me defining Mate0=ShrtMax , which makes scores higher than Mate0 wrong when stored in the tt using as "Short" , when I lowered Mate0 the problem disappeared

[Sven]

I think the cause of the wrong behavior is this coupled with me defining Mate0=ShrtMax , which makes scores higher than Mate0 wrong when stored in the tt using as "Short" , when I lowered Mate0 the problem disappeared

So you mean 16-bit integer overflow? That would be an explanation