Yet another Mate scores in TT thread

[AndrewGrant]

Cannot only return -MATE, without changing something else at least.

say we are in some node which is 5 from the root, and 3 from the mate. By returning -MATE, we will call this node a mate in 5 in the table (-MATE + 5), but really it is a mate in 9, 5 + 1+ 3.

[syzygy]

And finally, when I identify I am in a node which is checkmated, I say the value of this node is

Code: Select all

-MATE + height

I think this is your problem. If you are at a node where you are mated, you should return a value of -MATE.

Your height adjustment is handled in the valueToTT function but the adjusted score only goes into the TT. Your recursive search should still return -MATE.

The search should return the score relative to the root position, so the mate score corresponding to the distance from root to mate.

The TT should store the score relative to the node itself, so the mate score corresponding to the distance from the tree node to mate.

[Joerg Oster]

AFAIK this has nothing to do with TB?

It has everything to do with TB.

To ensure progress to mate on the board once mate has been found in the search, distance-to-mate scores are used. These need special TT handling of the range MATE-MAX_PLY to MATE.

To ensure progress to a TB win on the board once a TB win has been found in the search, dinstace-to-TB-win scores are used. These need special TT handling of the range MATE-2*MAX_PLY to MATE-MAX_PLY.

Thanks for the clarification.

Somehow I seemed to remember that this was mentioned as a bugfix somewhere.
I apologize for the misinformation.

[Karlo Bala]

Okay, so storing mate scores into the table. I use these two wrappers when I read or write a value to the TT. I've seen this in most form posts, and it is also in Stockfish. I assume this looks good.

Code: Select all

int valueFromTT(int value, int height){
    return value >=  MATE_IN_MAX ? value - height
         &#58; value <= MATED_IN_MAX ? value + height
         &#58; value;
&#125;

int valueToTT&#40;int value, int height&#41;&#123;
    return value >=  MATE_IN_MAX ? value + height
         &#58; value <= MATED_IN_MAX ? value - height
         &#58; value;
&#125;

And just for completeness. Here Stockfish uses 2 * MAX_PLY for defined MATED_IN / MATE_IN, which makes no sense to me, but both methods fail for me.
Pheraps the idea is that we the max height we probe the tt is ~MAX_PLY, and the max stored mate inside the tt is ~MAX_PLY, thus using 2*MAX_PLY we are safe... but then as far as I can see nothing is stopping stockfish from storing that

Code: Select all

#define MAX_PLY    (128)

#define MATE         (16000)
#define MATE_IN_MAX  (+MATE - MAX_PLY)
#define MATED_IN_MAX (-MATE + MAX_PLY)

And finally, when I identify I am in a node which is checkmated, I say the value of this node is

Code: Select all

-MATE + height

The "Usual" problem in these threads is people do not do any of this, thus their mate scores have no relation to the root, and then they are unable to determine better/faster mates.

AFAIK, that is not my problem. What will happen for me is that I will try to store values like 15849 into the table. This is equal to MATE - 151. No where should I ever be reaching a depth/height/ply of 151.

The initial though is that the search is using the tt to build up really long mating lines. Which I suppose IS possible, but I find that very hard to believe. I have zero idea what is going on here. I have tried disabling all pruning, ensuring pruning never returns mate scores, and yet the problem persists. I am also confident that my evaluation is never returning values like 15849, proven via assertions.

I've not managed to find this particular TT mate issue in any threads listed on chesswiki

Simple explanation:
https://www.ics.uci.edu/~eppstein/180a/990202a.html


However, it looks to me that your code is OK. Bug must be somewhere else.

[syzygy]

AFAIK this has nothing to do with TB?

It has everything to do with TB.

To ensure progress to mate on the board once mate has been found in the search, distance-to-mate scores are used. These need special TT handling of the range MATE-MAX_PLY to MATE.

To ensure progress to a TB win on the board once a TB win has been found in the search, dinstace-to-TB-win scores are used. These need special TT handling of the range MATE-2*MAX_PLY to MATE-MAX_PLY.

Thanks for the clarification.

Somehow I seemed to remember that this was mentioned as a bugfix somewhere.
I apologize for the misinformation.

Here is the original commit by Gary:
https://github.com/official-stockfish/S ... 65e772a344

It may well be that someone with an incomplete understanding of the issue denounced this as a bug at some point in time

[AndrewGrant]

So assuming that the highest mate score you will ever see is MATE - MAXPLY is wrong.

This would be a problem though, wouldn't it? If at some point we have a MATE - MAXPLY - X score floating around, any code that looks at mate scores is not going to see it as such.

As I store things in the table I am printing out any values that are very close to mate scores, but do not actually fall within [-MATE, -MATE + MAX_PLY] and [MATE - MAX_PLY, MATE].

After a pretty good chunk of time I'll see one or two values like MATE - MAXPLY - 4. And then as those values influence the search, I see many many many more of them.

Perhaps I am confusing your quote. Here I am saying MAXPLY is not the deepest line you searched in each iteration, but the deepest the engine will every search ie (I assume you did not mean this, so writing ID here is not meant to be condescending)

Code: Select all

for &#40;depth = 1; depth < MAXPLY; depth++)&#123;rootAlphaBeta&#40;);&#125;

I suppose a (although wrong?) solution is to have some new value LEADS_TO_MATE = MATE - MAXPLY - 1, where anytime we take something out of the table, if it is a mate score, we make sure that after the height adjustment (ttValue - height for +MATE scores) is either a proper mate score, or we set it to LEADS_TO_MATE