Yet another Mate scores in TT thread

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
AndrewGrant
Posts: 487
Joined: Tue Apr 19, 2016 4:08 am
Location: U.S.A
Full name: Andrew Grant
Contact:

Yet another Mate scores in TT thread

Post by AndrewGrant » Thu Apr 12, 2018 5:22 am

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    &#40;128&#41;

#define MATE         &#40;16000&#41;
#define MATE_IN_MAX  (+MATE - MAX_PLY&#41;
#define MATED_IN_MAX (-MATE + MAX_PLY&#41;
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
Posts: 689
Joined: Fri Mar 10, 2006 3:29 pm
Location: Germany

Re: Yet another Mate scores in TT thread

Post by Joerg Oster » Thu Apr 12, 2018 8:08 am

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.
Jörg Oster

AndrewGrant
Posts: 487
Joined: Tue Apr 19, 2016 4:08 am
Location: U.S.A
Full name: Andrew Grant
Contact:

Re: Yet another Mate scores in TT thread

Post by AndrewGrant » Thu Apr 12, 2018 5:08 pm

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.

User avatar
hgm
Posts: 23718
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Yet another Mate scores in TT thread

Post by hgm » Thu Apr 12, 2018 5:54 pm

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
Posts: 4455
Joined: Tue Feb 28, 2012 10:56 pm

Re: Yet another Mate scores in TT thread

Post by syzygy » Thu Apr 12, 2018 6:39 pm

AndrewGrant wrote: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
Posts: 487
Joined: Tue Apr 19, 2016 4:08 am
Location: U.S.A
Full name: Andrew Grant
Contact:

Re: Yet another Mate scores in TT thread

Post by AndrewGrant » Thu Apr 12, 2018 6:40 pm

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
Posts: 4455
Joined: Tue Feb 28, 2012 10:56 pm

Re: Yet another Mate scores in TT thread

Post by syzygy » Thu Apr 12, 2018 6:59 pm

AndrewGrant wrote: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
Posts: 1159
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: Yet another Mate scores in TT thread

Post by Ras » Thu Apr 12, 2018 8:32 pm

AndrewGrant wrote: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
Posts: 1159
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: Yet another Mate scores in TT thread

Post by Ras » Thu Apr 12, 2018 8:34 pm

syzygy wrote: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.

User avatar
Greg Strong
Posts: 388
Joined: Sun Dec 21, 2008 5:57 pm
Location: Washington, DC

Re: Yet another Mate scores in TT thread

Post by Greg Strong » Fri Apr 13, 2018 3:12 am

AndrewGrant wrote: 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.

Post Reply