Yet another Mate scores in TT thread

[AndrewGrant]

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

[Joerg Oster]

This is a known 'oversight' from an earlier patch, iirc.
Fixing it was part of Marco's "Natural TB" patch, but since that didn't get merged, it's still there.

[AndrewGrant]

AFAIK this has nothing to do with TB? I looked at Marco's patch, and he reduced the MATE_IN_MAX , MATED_IN_MAX to MATE-MAX_PLY, -MATE+MAX_PLY, but nothing else related to mating when there is no TB present ?

By oversight, are you suggesting that Stockfish might store near mate scores in the same way I am, by mistake? I ran stockfish on a number of positions with added LOC to catch that, but never saw it once.

[hgm]

It is not clear to me which problem you perceive. Over-the-horizon mates can be seen through grafting deeper TT results on nodes near the leaves of the real search tree. Sometimes this finds sub-optimal mates that are very deep, like mate-in-50 in a KRK end-game, when searching only 20 ply. So assuming that the highes mate score you will ever see is MATE - MAXPLY is wrong.

[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.

[AndrewGrant]

Only if table bases are being used though, I would assume?

I'm not running SF with table bases, and I'm not running Ethereal with them either.

[syzygy]

Only if table bases are being used though, I would assume?

Yes, not so many TB wins are detected if they are not used.

But there is no need in SF to change this at runtime depending on whether TBs are used.

[Ras]

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.

Are you sure that you are storing that value? Or are you only sometimes reading such a value? In the latter case, there might be some pointer error somewhere in the code that garbles memory.

[Ras]

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.

Or using TT entries only for move sorting when being in a PV node. That solves also the issue of PV truncation.

[Greg Strong]

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.