I already have reached the exact number of wins, but some draws have not been detected (unknown i/o draw).
I need to look into these unknown positions, and see what's missing in my static rules to initialize the process correctly.
I'm almost there! Going to bed now...
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
It is pointless to have initial rules for draws. In retrograde analysis all positions that remain unknown after you propagated the wins and losses are draws. Typically you would need very many rules to define all draws that you can be forced to, as in most draws you cannot force anything at all. They are just positions where you cannot make progress. I.e. they are a group of positions that are bounded by obvious draws (like in KPK stalemates and loss of the Pawn), but within which you can roam around freely.
E.g. did your draw rules capture distant oppositions (Ke2, Pe2, Ke7, btm)? Black cannot force the white King to approach him, and take regular opposition, or force white to advance his Pawn, so he can step in front of it. There is no reason why drawn positions can be forced from other drawn positions. But from any win-in-N you should be able to force a win-in-(N-1), or it would not have been a win-in-N. Therefore all wins are retrogradely reachable from win-in-0 = checkmates. For draws there is no such rule.
lucasart wrote:Exploiting the symmetry of the problem, we assume without restriction that white has the pawn, and the pawn is within [A2..D7] rectangle. So there are N = 64*64*24*2 elements in the bitbase (2 for side to move).
Out of these, how many draws are there ?
I need a unit test to validate my code -- like assert(nb_draws == ...). Nb of draws seems like a good unit test, just like perft values are a good unit test for board/movegen code. If everyone agrees on that number, it's likely to be correct. If it's not a good unit test as such, perhaps the number of draws for each of the 6 values of rank(white pawn) or something like that.
Also regarding rules used to initialize the generation, are these rules 100% correct at detecting a draw ? (even if the white pawn is on the 2nd rank and/or on a rook file)
Black king directly in front of the pawn, white king directly behind it, black to move.
Black king directly in front of the pawn, white king diagonally behind the pawn, white to move.
Some rules were produced 20 or so years ago which solve KPK perfectly - they can be substituted for a bitbase and are 100% correct. I don't have a source but they do exist somewhere.
It can be proved trivially that any bitbase can be replaced by a set of rules that will return the same result. The most trivial "rule" is to perform a search to find the answer. But can any or most databases be replaced with a decision tree or set of rules that execute quickly while representing a substantial space savings? I think the answer is "probably"
I think the rule for Rook and King vs King is that it's a win always unless black is stalemated or the rook is immediately subject to capture (and not defended by the king.) It wouldn't surprise me if there is some exception to what I just stated, it's maddeningly difficult to produce a perfect set of rules.
Don
Capital punishment would be more effective as a preventive measure if it were administered prior to the crime.