Suicide chess tablebases (stalemated player wins)

[niklasf]

Has anyone built 5 piece (or more) suicide tablebases with the "stalmated player wins" rule? Or does anyone have a generator that can do this?

In particular the Syzygy generator seems to have a -DSUICIDE flag, but I am not sure which stalemate rule it uses or if it is supported at all.

If such a set exists or we manage to create one I'd be happy to mirror it or even provide online lookup.

[syzygy]

Has anyone built 5 piece (or more) suicide tablebases with the "stalmated player wins" rule? Or does anyone have a generator that can do this?

In particular the Syzygy generator seems to have a -DSUICIDE flag, but I am not sure which stalemate rule it uses or if it is supported at all.

The github code is incomplete, but I have a fully functional suicide TB generator. It uses the FICS stalemate rule, but changing that to "stalemated player wins" should be a 1-line change.

2-5 piece WDL is 8.78 GB
2-5 piece DTZ is 1.08 GB

6 piece WDL is 318.17 GB
6 piece DTZ is 66.87 GB

Compared to the 2-5 piece WDL tables, the 6-piece WDL tables use an extra trick that halves their size (or so) at the cost of longer access time (more probing of 5-piece tables). If 6-piece tables are not generated, this trick could be used for 5-piece tables to decrease their size.

Generating all 5754 6-piece tables took a long time. And they all use the FICS rule... . Generating the 5-piece set should only be a matter of days, though.

If such a set exists or we manage to create one I'd be happy to mirror it or even provide online lookup.

I am still very impressed with https://syzygy-tables.info/ so I will look into adding the suicide TB generation code to the github repository.

[niklasf]

Great. Looking forward to it

[guyhaw]

Niklas,

Good to see plaudits for https://syzygy-tables.info/ ... with which I heartily agree.

Maybe you know of the announcement that Losing Chess is solved - in the sense that the initial position is known to be a win for White ... 1. e3.

http://magma.maths.usyd.edu.au/~watkins ... solved.pdf gives more details.

Guy

[syzygy]

Great. Looking forward to it

I have added the suicide generator, but I think a bug crept in somehow. So don't use it yet. (And it's anyway using FICS rules at the moment, but that is very easy to change.)

I have also added a generator for atomic chess just in case someone is interested.

[syzygy]

Generation of suicide TBs should be working correctly now.

Instead of making the "stalemated player wins" rule a compile- or run-time option, I have added a "giveaway" variant. This is suicide with the international rules (and corresponds to giveaway on ICC).

The suicide TB generators are stbgen for pawnless and stbgenp for pawnful tables. They generate .stbw and .stbz files. These use FICS rules. The generator looks for .stbw files for subtables in $STBWDIR and if that is empty in $PWD.

The giveaway TB generators are gtbgen and gtbgenp. They generate .gtbw and .gtbz files. These use international rules (stalemated player wins). The generator looks in $GTBWDIR etc.

Since stalemate in suicide is not possible without pawns, the TB files for suicide and giveaway for pawnless tables are necessarily identical (except for a different magic number and consequently a different internal checksum). The generator for either variant therefore accepts pawnless tables generated for the other variant (i.e. as subtables of the table being generated). All that is needed is a symlink from .stbw to .gtbw or vice versa. (.xtbz files for subtables are not used in TB generation). Of course this is irrelevant if you restrict yourself to international rules.

The atomic TB generators are atbgen and atbgenp (which predictably generate .atbw and .atbz files). 6-piece WDL/DTZ is 90.95 GB / 129.35 GB.

The highest 6-piece DTZ value (in my funny metric that takes care of the 50-move rule, to be precise) occurs in atomic for KQQvKQP (DTZ = 600):
[d]8/Q7/p6K/8/1Q3k2/8/8/q7 b - -
White wins (ignoring the 50-move rule).

The longest suicide win has DTZ = 208:
[d]8/7k/8/8/1p6/1P4K1/8/6BN w - -
Again white wins.

[niklasf]

Thank you very much.

Tablebase generation is still in progress. We can compare checksums once it's complete.

Meanwhile I am having a look at the probing code. I am assuming I have to use the code that was removed here https://github.com/syzygy1/tb/commit/2e ... 11d013f9c9 (since it doesn't make sense for vanilla Stockfish). Please stop me now if that's not the way to go

[syzygy]

Thank you very much.

Tablebase generation is still in progress. We can compare checksums once it's complete.

Meanwhile I am having a look at the probing code. I am assuming I have to use the code that was removed here https://github.com/syzygy1/tb/commit/2e ... 11d013f9c9 (since it doesn't make sense for vanilla Stockfish). Please stop me now if that's not the way to go

Yes, the suicide/giveaway TBs have special indexing code.

You can compare with the indexing code used in the generator:
https://github.com/syzygy1/tb/blob/master/src/probe.c

probe_wdl() / probe_ab() is different too, because capturing is compulsory. So if at least one capture exists, you should return the result of the best capture. If no capture exists, you should return the result of probe_table().

If you go for 6-piece (generation would take many months though), probing becomes more complicated. In a 6-piece position without captures, you have to try out all moves of the side to move that immediately force a capture by the other side and then call probe_table(). The value of the position is the max of the various outcomes. So this is only necessary for the 6-piece position itself, not for the 5-piece positions obtained after a capture.

Here is a probe_wdl() implementation (probe_tb()) that takes arrays of numpcs piece types and positions, a bitboard with the occupied squares, and alpha/beta bounds (from -2 to 2):
https://github.com/syzygy1/tb/blob/master/src/sprobe.c
Lines 148-149 skip the part where all "threats" are tried (i.e. moves that force a capture by the opponent).

probe_dtz() should not need many changes (but I haven't actually tried probing my suicide dtz tables, so... let's hope they work at all ).

[niklasf]

Thanks.

At the moment I am having trouble figuring out the header of a specific giveaway table, BBvNN.

According to https://github.com/syzygy1/tb/blob/d7f6 ... obe.c#L273 that should be the correct name, i.e. with white having the bishops, not NNvBB.

Code: Select all

$ hexdump BBvNN.gtbw | head -n1
0000000 55bc 21bc 1141 b2b2 2b2b 0600 010e 0244
                       ^^^^ ^^^^

Now in https://github.com/syzygy1/tb/blob/d7f6 ... be.c#L1882 we iterate over the highlighted bytes and

(0) mask with & 0x0f
(1) shift >> 4

Result:

Code: Select all

ptr->pieces[0] = { 2, 2, 11, 11 };
ptr->pieces[1] = { 11, 11, 2, 2 };

According to https://github.com/syzygy1/tb/blob/d7f6 ... defs.h#L42 this means white knights and black bishops, but the table should have only white bishops and black knights.

I tried to sample some standard chess tables, but none of them seem to have this mismatch.

What am I missing?

[syzygy]

Thanks.

At the moment I am having trouble figuring out the header of a specific giveaway table, BBvNN.

Yes, the generator interchanges white and black here to speed up generation (knights are less mobile than bishops so should be in the more significant bits of the index during generation). This is not done by the regular tb generator. (See here. The reason the regular tb generator does not do it is that the king is the least mobile piece and white always has a king. And I probably should add that the pawnless generator relies on the most significant piece being white. At least then it all makes sense, but it is some time ago that I wrote this code.)

The probing code has to correct for the switching around of white and black pieces in init_table_wdl by recalculating entry->key. The relevant part of the WDL probing code of the generator is this:
https://github.com/syzygy1/tb/blob/mast ... 2226-L2230
(The generator stores the lower 32 bits of the material signature key. The regular probing code in SF stores all 64 bits.)
This (re)calculation of entry->key does not hurt even where it is not needed.

Sorry for not mentioning this earlier. I've been bitten by it myself a few times, but it's easy to forget about it.

So the header is correct and your code is correct. You should just make sure that the material combinations are mapped correctly based on the header (and not just based on the TB name string, which can be misleading).