My KPk routine scores win and draw but also superimposes a positional score which is calculated special for this ending. It's probably overkill but is a vestige of the early days when computers could not search very deeply. What I do is give a little incentive for king and pawn advancement so that even on a 1 ply search it won't flounder around.
On a really shallow search a program can paint itself into a corner where it falls into a repetition and runs itself out of winning moves. It can never return to a previous position without it being scored as a draw by repetition.
Chan Rasjid wrote: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. So it seems all fine - should have no bugs. Many thanks to Gert.
It was exasperating trying to get my KPK codes to work. With bitases, it should be simple to implement the KPK routine. Basically, it is to return zero when probe to bitbase shows a draw. For a win, what I found needed is just to evaluate the distance to promotion for the pawn. The other evaluation is just that the lone king stays clear from the pawn and the promotion square. It is this simple. Yet it was not working!
What actually made it work this time around is I disabled all the lines of codes that involves fifty and repetition draws in my search functions. I think there are bugs. I have yet to examine what was wrong.
There is something that need to be noted about the KPK routine. For some 'difficult' KPK endings, it seems necessary to have the two pawn/lone king race to promotion and also the Kings' race to get near the pawn. Without these coding, the play may fail. I don't clearly know the reason yet.
sje wrote: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.
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.
Chan Rasjid wrote: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.
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?) :