7-men Syzygy attempt

[noobpwnftw]

So with some fiddling and help from https://github.com/jjoshua2/tb/

It seems at least some of the 7-men TBs can be produced. Here is the current code: https://github.com/noobpwnftw/tb/tree/7-men, and here are all 3-6 men + some 7 men TBs I've generated so far: ftp://112.73.74.24/pub/syzygy/

However, it failed at this line https://github.com/noobpwnftw/tb/blob/a ... ute.c#L552 when generating certain piece combinations, for example KQQRBNvK.

Logs here:

Code: Select all

./rtbgen -t 128 --disk KQQRBNvK
Found 533 tablebases.
number of threads = 128
Initialising broken positions.
time taken =   0:31.838
Calculating white captures.
time taken =   0:17.572
Calculating black captures.
time taken =   0:04.970
time taken =   0:06.162
time taken =   0:06.358
time taken =   0:10.668
time taken =   0:13.659
time taken =   0:26.850
Calculating mate positions.
time taken =   1:28.989
Iteration 1 ... done.
Iteration 2 ... done.
Iteration 3 ... done.
Iteration 4 ... done.
Iteration 5 ... done.
Iteration 6 ...
########## KQQRBNvK ##########

White to move:

50353929224 positions win in 1 ply.
19485324695 positions win in 2 ply.
28225943789 positions win in 3 ply.
1549221184 positions win in 4 ply.
243517440 positions win in 5 ply.
508342 positions win in 6 ply.
1236 positions win in 7 ply.

99858445910 positions are wins.
10832 positions are draws.
0 positions are losses.


Black to move:


0 positions are wins.
13398181230 positions are draws.
337200714690 positions are losses.

40252520554 positions lose in 0 ply.
23613041816 positions lose in 1 ply.
130186914772 positions lose in 2 ply.
54678294580 positions lose in 3 ply.
81532772392 positions lose in 4 ply.
5908260412 positions lose in 5 ply.
1026861706 positions lose in 6 ply.
2041596 positions lose in 7 ply.
6862 positions lose in 8 ply.

Longest win for white: 8 ply; 8/Q1R5/8/8/3N4/2B5/5k2/QK6 b - -

tb_size = 196209130320
find optimal permutation for wtm / wdl
[ 0] order: 2; perm:  2  3  4  6 14  5; 8000
[ 1] order: 2; perm:  2  4  3  6 14  5; 8011
[ 2] order: 2; perm:  2  6  3  4 14  5; 8000
[ 3] order: 2; perm:  2 14  3  4  6  5; 8000
[ 4] order: 2; perm:  3  2  4  6 14  5; 8000
[ 5] order: 2; perm:  4  2  3  6 14  5; 8012
[ 6] order: 2; perm:  6  2  3  4 14  5; 8000
[ 7] order: 2; perm: 14  2  3  4  6  5; 8000
[ 8] order: 2; perm:  3  4  2  6 14  5; 8011
[ 9] order: 2; perm:  3  6  2  4 14  5; 8000
[10] order: 2; perm:  3 14  2  4  6  5; 8000
[11] order: 2; perm:  4  3  2  6 14  5; 8006
[12] order: 2; perm:  6  3  2  4 14  5; 8000
[13] order: 2; perm: 14  3  2  4  6  5; 8000
[14] order: 2; perm:  4  6  2  3 14  5; 8000
[15] order: 2; perm:  4 14  2  3  6  5; 8000
[16] order: 2; perm:  6  4  2  3 14  5; 8000
[17] order: 2; perm: 14  4  2  3  6  5; 8000
[18] order: 2; perm:  6 14  2  3  4  5; 8000
[19] order: 2; perm: 14  6  2  3  4  5; 8000
[20] order: 3; perm:  3  5  6  2  4 14; 8000
[21] order: 3; perm:  6  5 14  3  2  4; 8000
[22] order: 3; perm: 14  5  6  3  2  4; 8000
[23] order: 3; perm:  2  5  6 14  3  4; 8000
[24] order: 3; perm:  4  5  6 14  2  3; 8000
[25] order: 3; perm:  5  6  2  4  3 14; 8000
[26] order: 3; perm:  5 14  2  4  3  6; 8000
[27] order: 3; perm:  5  2  6 14  3  4; 8000
[28] order: 3; perm:  5  3  4  6  2 14; 8000
[29] order: 3; perm:  5  4  6  2  3 14; 8000
[ 0] order: 2; perm:  2  3  6  4 14  5; 8000
[ 1] order: 2; perm:  2  3 14  4  6  5; 8000
[ 2] order: 2; perm:  2  4  6  3 14  5; 8000
[ 3] order: 2; perm:  2  4 14  3  6  5; 8000
[ 4] order: 2; perm:  2  6  4  3 14  5; 8000
[ 5] order: 2; perm:  2 14  4  3  6  5; 8000
[ 6] order: 2; perm:  2  6 14  3  4  5; 8000
[ 7] order: 2; perm:  2 14  6  3  4  5; 8005
[ 8] order: 3; perm:  2  4  5  6 14  3; 8000
[ 9] order: 3; perm:  2  3  5  6  4 14; 8000
[10] order: 3; perm:  2  6  5  3  4 14; 8000
[11] order: 3; perm:  2 14  5  3  4  6; 8000
[12] order: 3; perm:  2  5 14  6  3  4; 8000
[13] order: 3; perm:  2  5  3  6  4 14; 8000
[14] order: 3; perm:  2  5  4  3  6 14; 8000
Segmentation fault

I think the current piece encoding/decoding cannot handle cases of KKQRBN+X(which did not exist in 6 men).

I recall there was a thread here where its author Ronald explained the detailed mechanisms with mcostalba, but no luck with the search... any enlightenment is appreciated.

[noobpwnftw]

Also I tried building KRBNvKQN which has the longest mate among pawnless 7-men TBs, the step counter should overflow:

Code: Select all

Iteration 241 ... done.
...omitted...
Iteration 299 ... done.
Iteration 300 ... find_val: not found!

There is REDUCE_PLY which I believe halves the counter past it, but I strongly suspect it is not normal to see a longest mate index not found.

[Vinvin]

... when generating certain piece combinations, for example KQQRBNvK.
...

Please, don't generate 6 pieces vs a lone king. + they are useless to generate other endings.

[Dann Corbit]

... when generating certain piece combinations, for example KQQRBNvK.
...

Please, don't generate 6 pieces vs a lone king. + they are useless to generate other endings.

Not useless.
Fast to generate and I have a friend who is very keen to examine the statistics.

[noobpwnftw]

Found the thread:
http://www.talkchess.com/forum/viewtopic.php?t=59947

And the crash above seems to be the tb_size calculation from permute type 0 is not the largest possible in trylist.

[syzygy]

I think the current piece encoding/decoding cannot handle cases of KKQRBN+X(which did not exist in 6 men).

The encoding/decoding scheme in principle can deal with that, but there may be a 32-bit overflow in an intermediate calculation.

[syzygy]

Also I tried building KRBNvKQN which has the longest mate among pawnless 7-men TBs, the step counter should overflow:

Code: Select all

Iteration 241 ... done.
...omitted...
Iteration 299 ... done.
Iteration 300 ... find_val: not found!

There is REDUCE_PLY which I believe halves the counter past it, but I strongly suspect it is not normal to see a longest mate index not found.

I'm not sure why this happens.

There will indeed be problems with very long mates, but the generation part should be able to deal with them. The problem comes when compressing (too many possible values). I have basically solved that problem when implementing DTM, but that code has not yet been added to github. The solution will require a small change in the format too.

[syzygy]

And the crash above seems to be the tb_size calculation from permute type 0 is not the largest possible in trylist.

They all have the same size/index range.

[noobpwnftw]

The encoding/decoding scheme in principle can deal with that, but there may be a 32-bit overflow in an intermediate calculation.

Thank you for this information, then I will look into it and see if I can fix the index calculation overflow first.

They all have the same size/index range.

Indeed, they are of the same size.

[noobpwnftw]

int overflow happened with the factor[] array, now it seems to be working!