How to implement KPK ?

[Don]

Does KPK show up over the board? The real question here is: how frequently does KPK show up in the search tree. And the answer is: surprisingly often.

I have the complete DTM KPK tablebases for either side to move. They are FREE for anyone who might want to use them, as is the code needed to access them.

It may show up a lot in the tree, but from a pure programming improvement standpoint it has no measurable effect on the strength of the program. But I still really like having it in the program.

[Chan Rasjid]

Finally, I am able to get my KPK routine to work just as 'perfectly' as how all other programs play the KPK endings. I am using the KPK bitbase which Gert Mueller put up in the public domain.

If you use a bitbase, why so much testing before you probe it?

Just probe it and if is a win, return a winning value that is a bit smaller than the value for K+Q versus K minus a value proportional to the distance of the pawn to promotion. If this does not work, don't hack your KPK routine further, but debug your search.

I think I understand what you mean.

Maybe it is just my natural instinct to harbour distrust - in the completeness of Gert Muller's bitbase

There is indeed a further search bug - or rather a search issue. I have a parameter for root search to return when the pv repeats N times. It was set to 16 and it was insufficient. Setting it to 32 is ok. But then this repeat of pv at root is an issue I have not settled on. If I disable it, it may just search till depth 64 and I don't like it too much.

Rasjid.

[sje]

This is a difficult KPK position which requires coding for the piece races:
[D]4k3/8/8/8/K7/8/4P3/8 w - - 5 1[/D]

How can the half move counter be five when the full move number is one? The FEN input scanner should really check for this.

Anyways,
[d]4k3/8/8/8/K7/8/4P3/8 w - - 0 1[/d]

Symbolic says:

Code: Select all

[] dtbm
Ka3 Even
Ka5 Even
Kb3 MateIn23
Kb4 MateIn23
Kb5 MateIn23
e3 Even
e4 Even

[] dg
1 Kb3 Kd7 2 Kc3 Kc6 3 Kc4 Kd6 4 Kd4 Ke6 5 Ke4 Kd6 6 Kf5 Ke7 7 Ke5 Kd7 8 Kf6 Kc6
9 Ke6 Kb5 10 Kd6 Ka6 11 Kd7 Ka5 12 e4 Ka4 13 Kd6 Ka3 14 e5 Ka2 15 Kc5 Ka1 16
Kc4 Ka2 17 e6 Kb2 18 e7 Kc2 19 e8=Q Kd2 20 Qe4 Kc1 21 Kc3 Kd1 22 Qe5 Kc1 23
Qe1# 1-0

[Chan Rasjid]

Hello,

This is a difficult KPK position which requires coding for the piece races:
[D]4k3/8/8/8/K7/8/4P3/8 w - - 5 1[/D]

How can the half move counter be five when the full move number is one? The FEN input scanner should really check for this.

Anyways,
[d]4k3/8/8/8/K7/8/4P3/8 w - - 0 1[/d]

Symbolic says:

Code: Select all

[] dtbm
Ka3 Even
Ka5 Even
Kb3 MateIn23
Kb4 MateIn23
Kb5 MateIn23
e3 Even
e4 Even

[] dg
1 Kb3 Kd7 2 Kc3 Kc6 3 Kc4 Kd6 4 Kd4 Ke6 5 Ke4 Kd6 6 Kf5 Ke7 7 Ke5 Kd7 8 Kf6 Kc6
9 Ke6 Kb5 10 Kd6 Ka6 11 Kd7 Ka5 12 e4 Ka4 13 Kd6 Ka3 14 e5 Ka2 15 Kc5 Ka1 16
Kc4 Ka2 17 e6 Kb2 18 e7 Kc2 19 e8=Q Kd2 20 Qe4 Kc1 21 Kc3 Kd1 22 Qe5 Kc1 23
Qe1# 1-0

I too notice the error in the FEN position - the fifty counter should be 0. There is some bugs in xboard with editing positions when remnant information from previous games/positions corrupts the fifty counter on saving. I discovered it as I have to look into the fifty counter as the bug in my search was a corrupt fifty counter.

Now my KPK rountine is working perfectly. It is just probe KPK bitbase and then returning a value. The return for a probe win is the 'optimally correct' value as pointed out by Ronald - just 8xPawns - distance_to_promote.

My analysis output is (the only correct PV before queening?) :

info depth 41, score +7871 cp, time 7381 ms, nodes 22541387 nps 3053974, pv
a4b3 e8f7 b3c4 f7e6 c4d4 e6d6 e2e3 d6e6 d4e4 e6f6 e4d5 f6e7 d5e5 e7f7 e5d6 f7e8 e3e4 e8d8 e4e5 d8e8 d6e6 e8d8 e6f7 d8d7 e5e6 d7d6 e6e7 d6e5 e7e8q e5d4 e8d8 d4c3

Best Regards,
Rasjid.

[Chan Rasjid]

The game in pgn :

1. Kb3 Kd7 2. Kc4 Kd6 3. Kd4 Ke6 4. Ke4 Kd6 5. Kf5 Kd5 6. e4+ Kd6 7. Kf6
Kd7 8. e5 Kc6 9. e6 Kc5 10. e7 Kd4 11. e8=Q Kc4 12. Qe3 Kd5 13. Qf4 Kc5 14.
Ke6 Kb6 15. Kd6 Kb5 16. Qe4 Kb6 17. Qb4+ Ka6 18. Kc6 Ka7 19. Qb7#
{White mates} 1-0

Rasjid.