Second, timer tests show the pKprobe() is at least 30,000 times faster than the syzygy WDL probe. In most cases it will report the same result. Endgame table bases are often not probed until a certain depth and there may still be no horizon static evaluation for KPK endgames using endgame table bases.
Third, all piece and pawn endgames eventually search a position reduced to KPK. When the KP bitbase is used for horizon evaluations, it can help reduce the size of the endgame tree(test it!). Piece and pawn endgame evaluation is likely to fail at some point without some sort of KPK draw evaluation after exchanges.
Here is how I have developed the KP bitbase:
The bit table returns a draw=0, wtm unknown score=1, or btm unknown score=2 from the positions of the white pawn and the black king.
For KPK endgames, be careful on what final score to return for a known win. If the win score is returned as a value greater than the value of a queen, then the pawn may never queen. Undesirably, the position loops deeper trying not to queen the pawn. Thus, wins and unknown scores can be returned as the same small material (say 100) and position(PSQT) value. That is; the static evaluation does not change for non-drawn positions.
Observe from various table inspections that most KPK endgames are a win. If wins and unknown are values treated the same then we only have to look for forced draws. There are three drawing possibilities in KPK endings:
(1) outside passed pawn
(2) where weak king can force the opposition
(3) kings race for the pawn
Notice that for the first two possibilities, the position of the strong king is irrelevant. The draw only depends on the position of the weak black king. We can almost solve the entire KPK ending without knowing the position of the white king!
For example, in the following position the white king can be on any legal square and the position is still a draw with either side to move first:
[d]8/8/K1k5/P7/8/8/8/8 w - - 0 1
For the third possibility of kings racing for the pawn, the position has to be searched as "unknown but assume a win". The is safe in most cases. If the pawn can be captured on the next move then the position will resolve quickly as a draw. The bitbase can also help the weak side to triangulate into a drawn position. This is the small price the poor man has to pay.
Will the bitbase improve elo? Not much. But neither will syzygy WDL probes from my findings. This seems theoretically correct to include and should help solve endgame problems.
Finally, you will have to write your own code for your engine to probe the pKtable.
Code: Select all
// The Poor Man's KP Bitbase by Dennis Sceviour, 2019
static uint8_t pKtable[48][64];
void init_KP_bitbase() {
int sq,c,r;
int kingc,kingr,kingsq;
//preset table values as win or unknown
memset (&pKtable[0][0], 3 , 48 * 64);
for (sq = 8 ; sq < 56; sq++) {
c = sq & 7;
r = sq >> 3;
for (kingsq = 0 ; kingsq < 64; kingsq++) {
kingc = kingsq & 7;
kingr = kingsq >> 3;
//outside pawn
if (!c) {
if (kingc < 3) {
if (kingr>r) pKtable[sq-8][kingsq] = 0; //draw
if (kingr==r && kingc<2) {
pKtable[sq-8][kingsq] &= 1; //draw ktm
}
}
}
if (c==7) {
if (kingc > 4) {
if (kingr>r) pKtable[sq-8][kingsq] = 0;
if (kingr==r && kingc>5) {
pKtable[sq-8][kingsq] &= 1; //draw ktm
}
}
}
//add in front of pawn info
//if the losing king is one or two squares in front of the pawn, and the pawn has not reached the sixth then it is at least draw. White cannot get in front of the pawn. Black has the opposition or can take it.
if (r<5 && kingc==c) {
if (kingr>r && kingr<r+3) pKtable[sq-8][kingsq] = 0;
}
if (r==5 && kingc==c) {
if (kingr==(r+1)) pKtable[sq-8][kingsq] &= 1; //draw ktm
}
}
}
}
