Store that as DRAW.Ĭheck whether the black king can capture the unprotected white piece. For each found mate generate the retro moves and all positions reached store them as "MATE in 1"Ĭheck whether you have a stalemate. Generate all positions with black to move and look whether they are mate (or stalemate). I generate the tables in the order KRK, KQK, KPK This is how I do it for the 3 men on the fly when the engine starts (I use the convention that captured pieces are put on the same square as the white King.) Then I can generate the whole thing as if it was a single EGT.
#Generate chess endgame tablebase generator#
In my old generator I don't even make a distinction between the EGTs (as successors after capture are negligibly small anyway), and absorb all successor EGT into the main one, by using the 'broken positions' in the latter to store them. You can either do this by generating un-captures from these successors' won positions (you would do this on every iteration when building DTM), or you could just loop through the EGT you are building, to generate forward captures into the successor EGT, and probe the DTx there. If you build the EGT using backward moves, you should start (next to identifying all checkmate positions) by 'seeding' it from all its possible successor EGTs. How do you handle the captures in this backward move generation? I mean: if I have a KPK position, handling captures means that I should generate KPKN previous position where the pawn captures the knight, and so it produces the KPK position that I have? It is quite confusing.īackward captures ('un-captures') would leave the uncaptured piece on the from-square (which is the to-square of the corresponding forward move). Note that forward captures would reach into a successor EGT. (And for the won positions, you would not even have to generate forward moves, because the position you reached it through is guaranteed to be its daughter with the smallest DTx, if it doesn't have a smaller DTx already. in the latest iteration), because only the parents of those (which you reach by backward moving) then need to be treated this way. It is much faster to keep track of which positions are 'newly won' or 'newly lost' (i.e. It is a bit expensive to do this for all possible positions in every iteration, though. Where a position is won if any of its daughters is won (and then gets the DTx of that daughter + 1), and is lost if all of its daughters are lost (getting the largest DTx of any daughter, if you count in full-moves). In principle each iteration could loop through the entire tablebase, generating forward moves from every yet-undecided position, to examine the DTx of the daughter positions, and conclude its own DTx from those.
Not really it is mainly a (great) speedup. Asanjuan wrote:- a backwards move generation is needed?
0 kommentar(er)
