lichess.org
Donate

7-piece Syzygy tablebases are complete

Thank you so much Bojun Guo and Ronald de Man for recreating an amazing feature, making it so much better than it already was! I am very grateful for that and surely so are many others!
Now that 7-men tablebase is finished, a natural question is:
are there any attempts to generate 8-men tablebase?
Congrtas! That's fantastic!

This is going to improve master level chess. For an average player like me, I can only use this if I'm too curious about a result of a top game like in the upcoming Carlsen vs. Caruana.
I wonder how much smaller the 7-men tablebase would be, if all the "non-sense" endgames were removed.

A tablebase without:
6 vs 1
4N vs 1N
4N vs 1B
4B vs 1B
3N vs 2B (ie both bishops on white squares)
3Q vs 2N (way too strong)

etc.

I would say, a tablebase without 3% of the most irrelevant endgames?
The article mentions that the table-base would be already 1% smaller without the useless 6 vs 1, and there are probably quite a few more endgames we could easily do without. (And thus hopefully get the table base to a size which people can afford to have as SSD space)

It is nice to have the world record of a totally complete 7-men-tablebase, but practically seen, most of us are rather interested in endgames like these:
KRPP vs KRP
KRPP vs KRN
KRPP vs KRB
KBPP vs KBP
KNPP vs KBP

...and many more "useful" endgames, too many to list them, but you get the idea.

Also: to have some of the most relevant 8-men tablebases was really good.
Most relevant, I guess is:
KRBP vs KRNB
KRPP vs KRPP
KRPPP vs KRP
KRBP vs KRBP
KRNP vs KRNP
KBPPP vs KRP
KNPPP vs KRP
KBPP vs KNPP
KBPP vs KBPP
KNPP vs KNPP

I'd guess these would cover 98% of all practical endgames (of interest), but then again, I would not wonder if the amount of possibilities for just this small selection would still be too huge to be reasonable.

@Munich Due to the compression format "unimportant" endgames already are heavily compressed. E.g. you mentioned the 6v1 being only 1% of the storage space despite being a big chunk of the possible legal positions. On the other hand, the "relevant" tables are those that are harder to compress thus they are much bigger. Sure, you could remove all of the trivial ones, but does it really make such a big difference whether it's 18 TB or 15 TB?

Besides, an engine doesn't care if an endgame is important or not, if it gets hit in search it will get probed either way. Though AFAIK engines these days can handle incomplete TBs so feel free to only use the ones you want. (some old engines would have problems if tablebases were missing that were reachable, and basically every endgame is reachable from the clearly relevant KPPP vs KPP)

As for 8 men tables, the problem with those is the hardware needed to generate them. You would need approximately 60 TB of RAM to generate any 8 men table with the current algorithm. And you need all the "nonsensical" endgames to generate interesting ones like KPPP vs KPPP. (you need literally ALL other 4v4 tables to generate that one)
@Munich: Good point. We should investigate which tables give most playing strength. Ideally you would have a tool where you say how much disk space you have and it tells you a good combination of tables to download.

For 8-piece endgames, note that for example building KRPPvKRPP requires *transitively* (1) all endgames reachable by capture and (2) all endgames reachable by promotion.

(1) is fine, since we already have all 7-piece tables.

(2) requires lots of combinations which require combinations themselves and so on: KRPPvKRPP, KRNPvKRPP, KRNPvKRNP, KRNNvKRNP, KRNNvKRNN, KRBNvKRNN, KRRNvKRNN, KQRNvKRNN, KRBNvKRNP, KRBNvKRBN, KRRNvKRBN, KQRNvKRBN, KRRNvKRNP, KRRNvKRRN, KQRNvKRRN, KQRNvKRNP, KQRNvKQRN, KRNNvKRPP, KRBPvKRNN, KRBBvKRNN, KRRBvKRNN, KQRBvKRNN, KRRPvKRNN, KRRRvKRNN, KQRRvKRNN, KQRPvKRNN, KQQRvKRNN, KRBPvKRNP, KRBNvKRBP, KRBBvKRBN, KRRBvKRBN, KQRBvKRBN, KRBBvKRNP, KRRNvKRBB, KQRNvKRBB, KRRNvKRBP, KRRBvKRRN, KQRBvKRRN, KRRBvKRNP, KQRNvKRRB, KQRNvKRBP, KQRBvKQRN, KQRBvKRNP, KRBNvKRPP, KRRPvKRBN, KRRRvKRBN, KQRRvKRBN, KQRPvKRBN, KQQRvKRBN, KRRPvKRNP, KRRNvKRRP, KRRRvKRRN, KQRRvKRRN, KRRRvKRNP, KQRNvKRRR, KQRNvKRRP, KQRRvKQRN, KQRRvKRNP, KRRNvKRPP, KQRPvKRRN, KQQRvKRRN, KQRPvKRNP, KQRNvKQRP, KQQRvKQRN, KQQRvKRNP, KQRNvKRPP, KRBPvKRPP, KRBPvKRBP, KRBBvKRBP, KRBBvKRBB, KRRBvKRBB, KQRBvKRBB, KRRBvKRBP, KRRBvKRRB, KQRBvKRRB, KQRBvKRBP, KQRBvKQRB, KRBBvKRPP, KRRPvKRBB, KRRRvKRBB, KQRRvKRBB, KQRPvKRBB, KQQRvKRBB, KRRPvKRBP, KRRBvKRRP, KRRRvKRRB, KQRRvKRRB, KRRRvKRBP, KQRBvKRRR, KQRBvKRRP, KQRRvKQRB, KQRRvKRBP, KRRBvKRPP, KQRPvKRRB, KQQRvKRRB, KQRPvKRBP, KQRBvKQRP, KQQRvKQRB, KQQRvKRBP, KQRBvKRPP, KRRPvKRPP, KRRPvKRRP, KRRRvKRRP, KRRRvKRRR, KQRRvKRRR, KQRRvKRRP, KQRRvKQRR, KRRRvKRPP, KQRPvKRRR, KQQRvKRRR, KQRPvKRRP, KQRRvKQRP, KQQRvKQRR, KQQRvKRRP, KQRRvKRPP, KQRPvKRPP, KQRPvKQRP, KQQRvKQRP, KQQRvKQQR, KQQRvKRPP

This topic has been archived and can no longer be replied to.