Are there attempts at creating practical endgame tablebases?

As I understand it, 8-piece endgame tablebases have been in development for many years. The big issue is the sheer number of positions that are possible.

Are there any attempts at making a "practical" endgame tablebase, where the search is only over positions that might matter in actual games? For example, a KQQQ vs KB endgame is a 6-piece position, but it's trivial for the side with three queens to win even without a tablebase, so one should not need to devote actual computing power to solving it. Yes, there might be exceptions, but they would be so rare that focusing on the much more interesting and practically important endgames (e.g. KQP vs KRB) would be more productive.

• "it's trivial for the side with three queens to win even without a tablebase, so one should not need to devote actual computing power to solving it" Arguably it's not going to take a lot of computing power since it's that easy. At KQQQ vs KB there are a lot of winning moves, making it a short game.
– Mast
Jan 21, 2020 at 13:52
• I like the accepted answer, but wanted to point out that a "practical" endgame table is a chess engine strapped to a smaller endgame table. The purpose of endgame tables is to provide perfect play for all of these positions. Once you don't have play in the table, your chess engine takes over to find its way to a winning position. One would, of course, need to decide what the metric is for pruning. Perhaps a limit to how many TB of tables one has? Jan 21, 2020 at 18:08
• @Mast Interestingly, endgame table generation is not sped up by it being "simple." There may be a lot of winning moves, but endgame tables are typically looking for "the best." That is often defined not just to be checkmate, but mate in the minimum number of moves (which matters in a game that's pushing up against a move-limit). You still have to exhaust the nearly 2^36 positions that can arise. But a mate in 549 (KQNKRBN) is no more difficult for an endgame table than a mate in 2 with the same number of pieces. They're weird that way. Jan 21, 2020 at 19:40

There is a contradiction in terms in "only" generating practical endgame tablebases. We have to understand how tablebases are generated to see why.

Tablebases are generated by working backwards from the final mating/drawing positions, "retracting" moves rather than playing them forward. First, every possible final position is exhaustively listed. Then from each, we "retract" (take back) moves that could have been played. In doing so, we know a possible outcome of the resulting position (by playing forward to the final position again). Do this for all positions, and we know the ideal outcome of all of them.

Now what is a retraction? Pieces move backwards, so everything moves as in normal chess except pawns. Pieces can uncapture other pieces, leaving an extra piece on the board. Notably, pieces can unpromote into pawns.

Herein lies the problem. If you want to evaluate the "practical" endgames, you need to know all the final positions that could lead to them by retractions. If we agree KPPP v KB is a practical endgame (seems so), then we need to know the outcome of all KQQQ v KB endgames, since it might be the case that the only winning line is to reach a winning KQQQ v KB endgame. It is necessary to do these "trivial" endgames in order to do the practical ones.

(Preemptive counter-counterargument: not all KQQQ v KB positions are winning. Think of stalemates. This is another reason why we cannot handwave and say "all positions with this material balance are winning".)

Furthermore, the absurd KQQQ v KB might be necessary to correctly generate results for KQPP v KQBP or some dramatic pawn race endgame. If you don't check all the possible final positions (even absurd ones), you can never be sure that you didn't miss the only winning/drawing line.

The only possible "optimisation" of this sort you can do is to not generate, say K+6 v K endgames (which I think was the case for the 7-men tables, they skipped K+5 v K until everything else was done.)

• I believe KQQ vs KB is either an immediate stalemate (maybe there is a sequence allowing 2 moves but I doubt there is anything longer) or an easy win. But well, those are also trivial to analyze. I guess 500+ move thingies are the ones guzzling time due to tons of possibilities from both sides. Jan 21, 2020 at 13:21
• Ah, but KQQ v KQB with black sacrificing the queen for a stalemate? It's still necessary to work out KQQ v KB -- positions with more material depend on it. Jan 21, 2020 at 13:23

The answers given already should convince you it is not easy to concentrate on "practical". The case is not completely hopeless, though: if two of the pieces are pawns on the same line, chance is good that - while surely they can eat a piece - most optimal lines keep them there, greatly reducing the amount of computation. FINALGEN tablebase generator - A practical peek

• The issue with Finalgen apart from being notoriously slow is of course that for every endgame that you decide to keep it does take a lot of memory. I have in the past wondered whether someone could add some good compression to it. That being said, it can be quite powerful in some narrow circumstances, it once showed me some win in 100 or so in a queen endgame with quite a few pawns, which had been hopeless for the SF at the time. I suspect as engines get stronger there will be fewer and fewer positions where it can help though. Dec 5, 2021 at 18:22

It is difficult to define the exact boundary of practical vs. impractical. However, you can define this for yourself.

See this project

You can decide what you want to generate like:

rtbgen KQRvKR

However, as Remellion mentioned, there is a dependency between the different tables. For KQRvKR to function you will also need KQvKR, KRvKR and others so you would have to manage that yourself. I used this to create a pawn only table base since I didn't want to keep a full 6 or 7 piece tablebase.