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?) :