Tablebase suggestion

[jkominek]

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.

Same here. It's an appreciated addition. I wonder when it first went online. The supporting github repository was updated 3 months ago.

[syzygy]

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.

Same here. It's an appreciated addition. I wonder when it first went online. The supporting github repository was updated 3 months ago.

The link to op1-tables.info on syzygy-tables.info was archived for the first time on 10 November 2025:
https://web.archive.org/web/20251110071 ... _w_-_-_0_1
The directory with the tablebase files on the lichess server has some files dated 18-Oct-2025.
So they likely came online between those two dates.

Some discussion of the tables (not mentioning the web interface because too old) is here:

The "mate in 584" (DTC=584):
[d]R7/8/8/8/7q/2K1B2p/7P/2Bk4 w - - 0 1
https://op1-tables.info/?fen=R7/8/8/8/7 ... _w_-_-_0_1

[Geezer one]

I think that for a practical increase in playing strength (with chess engines), limiting pawn promotions to Queen only would be fine. There is probably less than 1% of positions that it would effect the result of.

You could also start getting rid of crazy imbalances of material. This would get tricky when a pawn is at the 7th rank, ready to promote, so rules could be introduced for that as well. Hopefully, these rules could be incorporated into the engine, so it knows whether to begin searching.

[jp]

...

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

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.
...

Same here. It's an appreciated addition. ...

Yes, good news! I take it "opposing pair" means at least one black and one white pawn on the same file?

[Geezer one]

Yes.

[hgm]

Subsets near the top of the mountain? I don't understand what that means. I thought a tablebase maker could simply omit a lot of the options when creating one, by removing combinations of pieces.

To correctly generate a tablebase with a pawn, you need to have previously generated the tablebases with the pawn promoted to a queen, rook, bishop, and knight. (Or you could limit to queen promotions and accept that you get incorrect results. You could then try to keep track of the assumptions you made and use those to correct the results returned by TB probes, and it all becomes an impractical mess that nobody will ever implement.)

That is not always true. If all promotions to Queen are already winning, there is no point in probing the successors reached through promoting to R, B or N. Outlawing possession of a second Queen usually only affects positions where the player has many Pawns on 7th rank, inexplicably waiting with promoting any of them until others reached 7th rank too. Failure to win those positions usually doesn't propagate backwards to earlier P-slices, which remain all-won through more sensible successors where you promote (to Queen) as soon as you can.

There is furthermore no need to consider all positions of an end-game with Pawns as a single tablebase, or generate them all at once. Each sub-set of positions with the Pawns in a fixed place ('P-slice') can be considered a separate EGT, and every irreversible move orders the EGT in a dependency chain. So it is very possible to only generate part of the positions with the same piece composition, leaving out the nonsensical ones (such as with 3 white Pawns on 7th rank, versus two black Pawns on 2nd). And it is in particular these non-sensical ones that would need multiple Queens for the strong side, and would allow promotions for the weak side. Even if you would declare any probe into such a 'silly' P-slice a loss for the strong side by default (so you don't need to generate them) the effect of that handicap would not propagate very far upstream to predecessor P-slices, which are still won by 'converting' to other successor P-slices than the silly one. So discarding the P-slices that are not totally won doesn't exclude a large fraction of the P-slices for that particulare piece combination.

[syzygy]

Subsets near the top of the mountain? I don't understand what that means. I thought a tablebase maker could simply omit a lot of the options when creating one, by removing combinations of pieces.

To correctly generate a tablebase with a pawn, you need to have previously generated the tablebases with the pawn promoted to a queen, rook, bishop, and knight. (Or you could limit to queen promotions and accept that you get incorrect results. You could then try to keep track of the assumptions you made and use those to correct the results returned by TB probes, and it all becomes an impractical mess that nobody will ever implement.)

That is not always true. If all promotions to Queen are already winning, there is no point in probing the successors reached through promoting to R, B or N. Outlawing possession of a second Queen usually only affects positions where the player has many Pawns on 7th rank, inexplicably waiting with promoting any of them until others reached 7th rank too. Failure to win those positions usually doesn't propagate backwards to earlier P-slices, which remain all-won through more sensible successors where you promote (to Queen) as soon as you can.

We have gone through this before. There will always be positions where you need an underpromotion and many more positions where a promotion is not winning. "Usually" is not enough to "correctly generate a tablebase".

(Or you could limit to queen promotions and accept that you get incorrect results. You could then try to keep track of the assumptions you made and use those to correct the results returned by TB probes, and it all becomes an impractical mess that nobody will ever implement.)

Everybody is free to prove me wrong on that last point.

There is furthermore no need to consider all positions of an end-game with Pawns as a single tablebase, or generate them all at once. Each sub-set of positions with the Pawns in a fixed place ('P-slice') can be considered a separate EGT, and every irreversible move orders the EGT in a dependency chain. So it is very possible to only generate part of the positions with the same piece composition, leaving out the nonsensical ones (such as with 3 white Pawns on 7th rank, versus two black Pawns on 2nd).

You will need to consider the nonsensical ones to be sure that you get the sensical ones right.

And it is in particular these non-sensical ones that would need multiple Queens for the strong side, and would allow promotions for the weak side. Even if you would declare any probe into such a 'silly' P-slice a loss for the strong side by default (so you don't need to generate them) the effect of that handicap would not propagate very far upstream to predecessor P-slices, which are still won by 'converting' to other successor P-slices than the silly one. So discarding the P-slices that are not totally won doesn't exclude a large fraction of the P-slices for that particulare piece combination.

Unless you want to have endless complexity, a generated P-slice is either correct or not. One "tainted" position spoils the whole slice.

I would be surprised if you can correctly solve (and know that you correctly solved) many P-slices without accessing nearly all of their direct parent slices for at least one position (it might be possible to skip B- and R-promotions after verifying that a non-winning Q-promotion does not lead to immediate stalemate, but there are probably some strange cases where you need to underpromote even though you can't see that directly). And the same for those parent slices. All the parent slices you access must be correctly generated.

[Geezer one]

Much like the Opposing pawn endings, limiting promotions to Queen is a way to get more endgames in a smaller size. We cannot get perfection in chess, but if we can get engines with a stronger elo, that is a goal worth striving towards.

[Geezer one]

Here is another exciting thing to consider. If we can get tablebases up to 9 or 10 pieces (with Q promotion only, limited minor/major pieces, no extreme material imbalances etc.) we can 'half' solve chess.

Opening theory is well developed, maybe not perfect, but we could have engines calculating all the way to the end, out of the opening. I predict it will be wrong less then 0.1% of the time (due to knight underpromotion etc.). That is good enough for the public IMO.

[Geezer one]

Another fun thing we could do is add common configurations to the tablebase. For example, commonly the pawns near the king are intact. If we add just positions like that, potentially we could 'flag' them to the chess engine, and it will only start searching once the correct conditions are met. In this way, we could have higher piece-count tablebases where it concerns the standard game.