Yet another Mate scores in TT thread
Posted: Thu Apr 12, 2018 7: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.
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
And finally, when I identify I am in a node which is checkmated, I say the value of this node is
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
Code: Select all
int valueFromTT(int value, int height){
return value >= MATE_IN_MAX ? value - height
: value <= MATED_IN_MAX ? value + height
: value;
}
int valueToTT(int value, int height){
return value >= MATE_IN_MAX ? value + height
: value <= MATED_IN_MAX ? value - height
: value;
}
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)
Code: Select all
-MATE + height
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