Hello,
for fun (as everything else here!) I implemented the KQK endgame tablebase. Now I'm looking for a method to test its correctness. I fed some positions to the engine, however search is not stable enough. I see that the first move at iteration 1 is a mate in N, then the search often settles on a longer mate (eg N+1). I think I can disable everything search-related and revert to a plain AB to prove the correctness of the TB, but I'm trying to figure out if there is a better approach. Of course I'm not willing to take an existing TB since it would require to understand other code as well as mine, doubling the effort )))
You can download this file : https://www.dropbox.com/s/3or245ruu7r2n ... D.ZIP?dl=0
Inside you'll find a file "KQK-9moves.epd", the field DM (distance to mate) is filled, there's a lot of 9 moves and a couple of 10 moves.
When the tablebase statistics (i.e. number of positions with a particular DTM) is the same as those published for other flavors of end-game tables there is little reason to doubt the correctness of your own.
mate in 0: 364 mated in 0: 364
mate in 1: 2448 mated in 1: 1352
mate in 2: 5012 mated in 2: 2956
mate in 3: 9064 mated in 3: 7480
mate in 4: 19964 mated in 4: 14144
mate in 5: 26164 mated in 5: 25484
mate in 6: 32064 mated in 6: 39908
mate in 7: 32104 mated in 7: 54052
mate in 8: 15000 mated in 8: 43800
mate in 9: 2680 mated in 9: 11300
mate in 10: 8 mated in 10: 56
Elapsed time: 0.172000
xmas79 wrote:I think I can disable everything search-related and revert to a plain AB to prove the correctness of the TB, but I'm trying to figure out if there is a better approach.
A straightforward way to verify the correctness of a TB is by looping through all positions of the TB and recomputing the value of the position using a 1-ply search (probing the TB or a sub-TB at each leaf position). If for all positions the result returned corresponds to the value stored, the TB should be correct.
Comparing statistics as suggested by HGM is easier, but may be tricky if you eliminate symmetrical positions from the TB by mirroring and the TB you want to compare statistics with does this differently.
Indeed, I should have mentioned that the counts I showed are the true counts, and not in anyway symmetry-reduced.
But even if you would compare symmetry-reduced results, and they are the same, it would be pretty amazing if the one you compared to would use a different symmetry reduction or if either of you were in error. It would just not be conclusive if you noticed a difference.
Ferdy wrote:Could you post sample positions where your search appeared to be not stable?
Positions like [d]8/8/8/8/3K4/Q7/3k4/8 w - - 0 1
It said mate in 3, then suddenly mate in 5 and sticked to it. I suspect it was the probing code, it was messing up the search by not adjusting correctly the mate distance by ply. Now everything seems fine.
xmas79 wrote:
Positions like [d]8/8/8/8/3K4/Q7/3k4/8 w - - 0 1
It said mate in 3, then suddenly mate in 5 and sticked to it. I suspect it was the probing code, it was messing up the search by not adjusting correctly the mate distance by ply. Now everything seems fine.
)))
