Tablebase suggestion

[Geezer one]

I don't know how to understand that as a meaningful suggestion to tablebase generation.

Each individual position is going to be too specific to judge with a W/D/L traditional eval. Say if we split the load, with seperate computers going through seperate sets of pieces, possibly it could be done. Generating one 8-piece set at a time, and then using a server level CPU to remove any position over or below X eval (say +5 or -5).

The idea is of course that we will save space, and use a CPU to deal with the technical winning line, if it comes up during a game.

[hgm]

I understand the logic of using bounds: if a position yields the same result under both 'Assume Loss' and 'Assume Win' for the missing conversion, its value is indeed mathematically proven regardless of the true value of that missing link.

However, my main concern is empirical rather than theoretical. By treating the missing tablebases as a variable bound, we might end up with a tablebase where a very large fraction—perhaps the majority—of positions are flagged as 'Undecided'.

The solution to that is also empirical. You will kno how many positions in the table are undecided once you generate it. If that is an unbearably large fraction the missing successor apparently contains the essential lines through which such an end-game should be typically won, and there are no alternatives, not even (DTZ-wise) slower ones. There are then two possibilities: either you have to generate the missing one after all, or you can discard the generated one as not worth it, and also treat it as missing. This decision will be affected by whether you will contain the particular end-game as important or non-sensical.

This is where the P-slices come in. In an ending with Pawns restrictions on their promotion (to stay away from missing tables) will in general not cause undecided positions to be spread homogeneously over the P-slices. Most P-slices have no Pawns on the 7th rank, and are not directly affected by promotion restrictions. The effects of the latter have to propagate to them retrogradely from P-slices where promotion is possible. Each such propagation step has the tendency to reduce the effect of the undecided positons in the successor; they will try to find a more favorable constellation of their mobile pieces before pushing the Pawn to convert to the successor P-slice, to reach a decided position instead of the undecided one, and often this succeeds. (As I illustrated in the KPK example for the no-underpromotion restriction.)

The underpromtion issue directly affects all P-slices with 7th-rank Pawns. But we know that the necessity for underpromotion is very rare. By far the most common cases are promoting to Rook to avoid an immediate stalemate, or to Knight to promote with check. Both require a very specific location of the enemy King and often some of the other pieces as well. That makes it relatively easy to find an alternative by first adjusting the position of the other pieces before promoting. The 'single promotion piece' restriction only affects a second promotion, and usually the alternative exists to first trade / sac the promotion piece you already have for the opponent's one (or his advanced passer) before promoting your second Pawn. If you cannot stop opponent passers outright while being a Queen ahead. Because Queens are so proficient in perpetual checking they are much more valuable to a defender than the attacker, and leaving extra Queens on the board makes it questionable whether you could force a second promotion at all. So trading away the result from any opponent promotion immediately in general offers much better prospects for winning, so that forbidding the alternative would only turn relatively few won positions to undecided.

But again, you will know when you generated the table. And then you could decide to allow two Queens after all, and also generate KQQRPkqrpp. The P-slices of this would still only have 7 mobile pieces. And the white advantage is so large that it is very likely a forced mate can be found without pushing any Pawns, or allowing the opponent to do so. If pieces have to be traded in the course of defending against mate, you will convert to KQRPkrpp or KQQPkqpp, which has P-slices with only 5 mobile men. All this is still a lot easier than solving KQQQRkqqqr.

[hgm]

It could be very interesting to implement this approach not necessarily for generating tablebases for use during a search but to solve a given endgame position. Then you don't need to (try to) generate and store all P-slices but just those that are relevant to the position. I think a similar approach, perhaps even the same approach, has been implemented in the past in programs like Freezer and Finalgen, but as far as I am aware these are now older programs and can probably be improved upon.

Indeed, this was exactly the idea that set me thinking about this. I wanted to build on-the-fly EGT generation in an engine, where the search would keep statistics on which P-slices of few-mobile-men positions it reaches, and would devote some of the processing power to generating EGT for those P-slices and their reachable successors for those that are most frequently evaluated.

[hgm]

The idea is of course that we will save space, and use a CPU to deal with the technical winning line, if it comes up during a game.

The problem of course is that you cannot leave out positions from an EGT 'to save space'. Because EGT, to save space, do not identify the positions they contain information about (such as the DTZ) by any other means than their location in the list of position. So leave out one position and all DTZ for positions behind it in the EGT will now be misinterpreted as belonging to a different position.

Another problem with your idea is that it is not practical. Generating an EGT through retrograde analysis takes just a few CPU cycles per position, any meaningful search on them easily a million times more. So if it takes 1 months to generate a certain large EGT...

[syzygy]

I don't know how to understand that as a meaningful suggestion to tablebase generation.

Each individual position is going to be too specific to judge with a W/D/L traditional eval. Say if we split the load, with seperate computers going through seperate sets of pieces, possibly it could be done. Generating one 8-piece set at a time, and then using a server level CPU to remove any position over or below X eval (say +5 or -5).

The idea is of course that we will save space, and use a CPU to deal with the technical winning line, if it comes up during a game.

By any chance, are you thinking of a tablebase as a list of FENs and some information per FEN?
If not, how would you propose to "remove" a position?

So this is not how tablebases work. If you do know how they work, reread my previous answer.

Maybe you could also try to calculate the number of positions in a single 8-piece tablebase (say KRBPvKRNP) and calculate the time you need to evaluate each position for say 10ms. Let's have 1000 CPUs working on them in parallel. How long does it take?

[Ajedrecista]

Hello:

Hello Ronald:

[...]

The 8-men positions with 1 opposing pair have been computed by Marc Bourzutschky (DTC metric) and are accessible here:
https://op1-tables.info/

8-men with 1 opposing pair only needs 82.5 GB of RAM with 1 byte per position if you split it up in pawn slices with the pair fixed, so it does not need a big machine.
9-men with 2 opposing pairs should only need 1.2 GB of RAM with 1 byte per position.
[...]

I knew about the existance of some 8-man EGTB, but I did not know about their public availability! Thank you very much for pointing to them.

Regards from Spain.

Ajedrecista.

They work fine, as expected. I tried the following 8-man endgame that is easy for SF:

[d]8/8/8/8/3p1p1p/5P1P/3k3K/5B2 w - - 0 1

Only Bb5 draws! The rest of moves lose. I try to guess the reason of the move: maybe to go to a4 and control the a4-d1 diagonal because d1 is the queening square and the black king can not control both squares (a4 and d1) at once. (It sounds familiar to me that I found the same idea of Ba4-Bd1 against a d-passed-pawn before, like I get into the same resource from time to time). There are many double-edged sidelines in this apparently easy endgame, for example the greedy 3.- ..., d2?:

[pgn][Event ""]
[Site ""]
[Round ""]
[Date "2026.01.23"]
[SetUp "1"]
[FEN "8/8/8/8/3p1p1p/5P1P/3k3K/5B2 w - - 0 1"]
[Result "1/2-1/2"]

1.Bb5! d3 {(1...Ke3 also draws)} 2.Kg1 {(2.Kg2 also draws)} 2...Ke3 3.Kf1 Kxf3! (3...d2? 4.Be2! Kd4 5.Kf2 Kc3 6.Bd1! Kd3 7.Ba4 Kd4 8.Ke2 Kc3 9.Bd1 1-0) 4.Bxd3 {(Only 4.Kg1? loses)} 4...Kg3 5.Bb1 Kxh3 6.Ke1 Kg2 7.Kd2 f3 8.Be4! h3 9.Ke3! h2 10.Bxf3+ Kg1 11.Bh1 Kxh1 12.Kf2! 1/2-1/2[/pgn]

If anyone is interested, one move earlier with the black king on d3: ..., Kd2 is an avoid move, while both ..., Kc2 and ..., Ke3 win.

Regards from Spain.

Ajedrecista.