Simplest use of syzygy table

[xr_a_y]

As always, I'm trying to be short in Minic and thus try to make a very simple use of syzygy TB.

So at non-root-node I do this (even inside PV): if a wdl score is available, I return it, adding the static evaluation to it if it is a real win/loss, TB_WIN_SCORE being +2000cp. I add evaluation so that search leads to mate in classic endgame (eval is using the classic push to edge things).
I always update TT entry as "exact" score with a giant depth.

Code: Select all

    ScoreType tbScore = 0;
    if ( !rootnode && skipMove==INVALIDMOVE && (countBit(p.allPieces[Co_White]|p.allPieces[Co_Black])) <= SyzygyTb::MAX_TB_MEN && SyzygyTb::probe_wdl(p, tbScore, false) > 0){
       ++stats.counters[Stats::sid_tbHit1];
       if ( abs(tbScore) == SyzygyTb::TB_WIN_SCORE) tbScore += eval(p, gp);
       TT::setEntry({INVALIDMOVE,createHashScore(tbScore,ply),tbScore,TT::B_exact,DepthType(200),computeHash(p)});
       return tbScore;
    }

At root, I use TB to generate suggested moves.

Code: Select all

    if (rootnode && (countBit(p.allPieces[Co_White] | p.allPieces[Co_Black])) <= SyzygyTb::MAX_TB_MEN) {
        ScoreType tbScore = 0;
        if (SyzygyTb::probe_root(*this, p, tbScore, moves) < 0) { // only good moves if TB success
            if (capMoveGenerated) generate<GP_quiet>(p, moves, true);
            else                  generate<GP_all>  (p, moves, false);
        }
        else ++stats.counters[Stats::sid_tbHit2];
        moveGenerated = true;
    }

The question is simple ... Am i doing it right ?

[Joost Buijs]

To me it looks fine, I don't know what your piece values are, in my engine I use use 300 cp for checkmate, and I would choose 150 or 200 cp for a win score from the EGTB. I've never used syzygy, only Nalimov which is DTM and this has to be treated differently. In the new engine I'm working on I will also add syzygy WDL in the hope I can find the outcome of the game a few plies earlier, I won't use syzygy DTZ, Nalimov sometimes finds a cursed win, but this is very sporadic, in the hundreds of games i played it happened once or twice that the engine thought it found a win, but it actually turned out to be a draw due to the 50 move rule.

[xr_a_y]

To me it looks fine, I don't know what your piece values are, in my engine I use use 300 cp for checkmate, and I would choose 150 or 200 cp for a win score from the EGTB. I've never used syzygy, only Nalimov which is DTM and this has to be treated differently. In the new engine I'm working on I will also add syzygy WDL in the hope I can find the outcome of the game a few plies earlier, I won't use syzygy DTZ, Nalimov sometimes finds a cursed win, but this is very sporadic, in the hundreds of games i played it happened once or twice that the engine thought it found a win, but it actually turned out to be a draw due to the 50 move rule.

There is a missing 0 in your cp values I guess.

What confuse me is how I'll get "mate in N" score if I always return TB score + eval ?

[jdart]

What confuse me is how I'll get "mate in N" score if I always return TB score + eval ?

You won't get a mate score with Syzygy unless your search finds a mate.

If I get a score from the tablebases at the root, I just return that, not TB score + eval. If there is a tablebase win I return a score that is above all other scores, but below known distance to mate scores.

If you are using the latest version of Fathom you can adjust the scoring constants in tbconfig.h so that Fathom scoring values match up to what your engine expects for scores. See https://github.com/jdart1/arasan-chess/ ... tbconfig.h for example.

[xr_a_y]

If I get a score from the tablebases at the root, I just return that, not TB score + eval. If there is a tablebase win I return a score that is above all other scores, but below known distance to mate scores.

Then how the engine will go for the mate if every score from TB is always "KNOWN_WIN" ?

If you are using the latest version of Fathom you can adjust the scoring constants in tbconfig.h so that Fathom scoring values match up to what your engine expects for scores. See https://github.com/jdart1/arasan-chess/ ... tbconfig.h for example.

Yes I do that redefining

Code: Select all

const ScoreType TB_CURSED_SCORE = 1;
const ScoreType TB_WIN_SCORE = 2000;

[jdart]

Then how the engine will go for the mate if every score from TB is always "KNOWN_WIN" ?

It may not go towards mate in a way that always minimizes distance to mate, but it will progress towards mate if there is one because it will always choose a winning move over one that draws or loses.

--Jon

[xr_a_y]

Then how the engine will go for the mate if every score from TB is always "KNOWN_WIN" ?

It may not go towards mate in a way that always minimizes distance to mate, but it will progress towards mate if there is one because it will always choose a winning move over one that draws or loses.

--Jon

ok get it thanks. So it's worth trying to accelerate that using a bit of eval in it I guess.

[Joost Buijs]

To me it looks fine, I don't know what your piece values are, in my engine I use use 300 cp for checkmate, and I would choose 150 or 200 cp for a win score from the EGTB. I've never used syzygy, only Nalimov which is DTM and this has to be treated differently. In the new engine I'm working on I will also add syzygy WDL in the hope I can find the outcome of the game a few plies earlier, I won't use syzygy DTZ, Nalimov sometimes finds a cursed win, but this is very sporadic, in the hundreds of games i played it happened once or twice that the engine thought it found a win, but it actually turned out to be a draw due to the 50 move rule.

There is a missing 0 in your cp values I guess.

What confuse me is how I'll get "mate in N" score if I always return TB score + eval ?

Of course you're right, there are 2 zero's missing, I meant 300 p or 30.000 cp for checkmate. So I would choose a value for an absolute win that is higher than what the material and positional evaluation combined could ever reach.

Nalimov returns distance to mate, so you don't want to add an evaluation score, you only have to compensate for the ply-depth at which the probe took place.

[Joost Buijs]

What I often see when I play against engines that use syzygy WDL (when they are in a won position) is that they find the win early and after this they start shuffling with DTM not changing or even getting worse sometimes, eventually they will win but it takes many more moves than necessary, just like the behavior of LC0. This is why I prefer DTM.