7-men Syzygy attempt

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
noobpwnftw
Posts: 237
Joined: Sun Nov 08, 2015 10:10 pm

7-men Syzygy attempt

Post by noobpwnftw » Sat Mar 10, 2018 4:14 pm

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
Posts: 237
Joined: Sun Nov 08, 2015 10:10 pm

Re: 7-men Syzygy attempt

Post by noobpwnftw » Sat Mar 10, 2018 11:11 pm

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
Posts: 4110
Joined: Thu Mar 09, 2006 8:40 am

Re: 7-men Syzygy attempt

Post by Vinvin » Sun Mar 11, 2018 12:17 am

noobpwnftw wrote:... 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
Posts: 8953
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: 7-men Syzygy attempt

Post by Dann Corbit » Sun Mar 11, 2018 1:16 am

Vinvin wrote:
noobpwnftw wrote:... 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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

noobpwnftw
Posts: 237
Joined: Sun Nov 08, 2015 10:10 pm

Re: 7-men Syzygy attempt

Post by noobpwnftw » Sun Mar 11, 2018 6:17 am

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
Posts: 4311
Joined: Tue Feb 28, 2012 10:56 pm

Re: 7-men Syzygy attempt

Post by syzygy » Sun Mar 11, 2018 12:05 pm

noobpwnftw wrote: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
Posts: 4311
Joined: Tue Feb 28, 2012 10:56 pm

Re: 7-men Syzygy attempt

Post by syzygy » Sun Mar 11, 2018 12:12 pm

noobpwnftw wrote: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
Posts: 4311
Joined: Tue Feb 28, 2012 10:56 pm

Re: 7-men Syzygy attempt

Post by syzygy » Sun Mar 11, 2018 12:13 pm

noobpwnftw wrote: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
Posts: 237
Joined: Sun Nov 08, 2015 10:10 pm

Re: 7-men Syzygy attempt

Post by noobpwnftw » Sun Mar 11, 2018 1:07 pm

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
Posts: 237
Joined: Sun Nov 08, 2015 10:10 pm

Re: 7-men Syzygy attempt

Post by noobpwnftw » Sun Mar 11, 2018 3:43 pm

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

Post Reply