CCRL Discussion Board

Nalimov not only excludes positions where the kings are adjacent, but also other "unblockable" checks. For example, a white knight on f6 and black king on g8 with wtm is illegal regardless of where the other pieces are, similar for example a white rook on f8 and a black king on g8. These e...

The Nalimov "broken" positions exclude certain illegal positions already, such as multiple pieces on the same square, and a subset of cases where the king of the side not to move is in check.

Since the board is so crowded in minichess even with a small number of pieces, and the pawns don't have far to go before conversion, one would expect DTC and DTZ to be close together and close to WDL in terms of compactness. As the board size increases, the differences will increase. I'm not sure wh...

White wins in 38 moves (DTC) with 1.Qg4+!

The first position is a draw (white can build a fortress after 1.Bg4 e1=Q 2.h3, while the second position is won for Black. This is from a 7-man database, albeit without underpromotions to 7-man subgames. However, in these positions underpromotions without a prior capture are almost certainly not go...

I started generating 7-man tablebases for the endings rook + 2 pawns vs. 2 minor pieces some time ago, with the constraint of promotions only to queen to avoid having to generate tons of sub-games. This case here with 2 bishops is almost done. The longest DTC is 107. I should be able to post some a...

I started generating 7-man tablebases for the endings rook + 2 pawns vs. 2 minor pieces some time ago, with the constraint of promotions only to queen to avoid having to generate tons of sub-games. This case here with 2 bishops is almost done. The longest DTC is 107. I should be able to post some a...

I started generating 7-man tablebases for the endings rook + 2 pawns vs. 2 minor pieces some time ago, with the constraint of promotions only to queen to avoid having to generate tons of sub-games. This case here with 2 bishops is almost done. The longest DTC is 107. I should be able to post some an...

The default behavior for the engines I know is to pre-initialize all the Nalimov endings in the EGTB paths provided. This is rather costly, since for each ending it will read the header of the compressed file and initialize an index file with 4 bytes for each block of 8k positions. This is well over...

I constructed a complete DTM (distance to mate) database for 3x4 chess. In total there are 167,303,246,916 unique legal positions (taking into account all possible symmetry). I still need to complete verification, compress the database, and run some statistics (including search for the longest DTM ...

The work by user Volodya on the Rybkaforum looks legitimate and very interesting.

Anyone try this on any 7-man endings yet? krrnkrr would be interesting, it is 4 times smaller than a regular pawnless 7-man ending and should have DTM >= 290.

In gtbgen I included "DTC(50)" because for pawnless endgames DTC=DTZ, and the adaptation of the Nalimov algorithm for DTZ is much slower than for DTC. So I created DTZ(50) by creating pawnless endgames with DTC(50), and then the pawnful endgames with DTZ(50). I don't think I included DTM(5...

Attached are stats files for kqnkrbn and krbnkqn in quasi-Nalimov format. If one wanted, one could combine them into one .tbs like file, as all wtm lost positions in kqnkrbn are btm lost positions in krbnkqn. For example, since there are about 32 billion positions in kqnkrbn that are "not won&q...

Arpad,

the first position is a win for white, with mate or capture in at most 88 moves after 1.Rd1.

the second position is a draw.

Regards,
Marc

Th ese results are quite reasonable, especially if there were many like pieces in the ending, as FEG does not implement permutation symmetry until the final compression stage. -Marc Greetings, FEG.exe did complete a 5-1 egtb successfully.. or *I guess successfully* However it seems odd. When I had c...

After having computed a fair number of 7-man tablebases without pawns, Yakov Konoval and I have now started on endgames with pawns. These will be of more practical interest than the pawnless ones, although will likely contain no new depth records. We think that the 517 moves to conversion in QNxRBN ...

Kirill Kryukov wrote:Hi Josh, I thought that only kqpkrp and kqpkbp need to be converted? Which means we can continue distributing other sets? Please correct me if I am wrong.

To make absolutely sure, we should only distribute those sets where the md5sums have been matched as well (in addition to file sizes).

Comparing the Nalimov generated tablebases with those obtained through Johan de Koning's FEG we so far have 100% agreement. The .tbs statistics files are identical, and the compressed file sizes are (almost) all identical. md5 comparisons will also be done and I expect those to be identical as well....

Hello Thomas, the file splitting for Nalimov tablebases is absolutely unique. Please have a look at the thread "EGBT file splitting". The uncompressed files are broken every 2^31 bytes and then compressed individually. You can even get the splitting program by Marc in that thread. Greetin...

Les, If your argument was correct, the number of wtm and btm broken positions would be the same for a given endgame. It very rarely is. Your mistake is that a wtm position in KRNKPP is a 'KRN'-to-move position: switch colours to KRN=Black, and you have a btm position in KPPKRN (which is equivalent ...

[re MB...] Piece/pawn collision, ah yes. I remember 'reverse engineering' some small-endgame index-ranges with Eugene in 1999 in order to prise out the details. I think I said it was a good argument for 'placing' the Pawns after the Kings (even 'before the Kings' for P-profile partitioning). Then t...

... Thus the Nalimov .tbs files for KPK, KNKN have no broken positions. Those for KNKP, KPKP and (a fortiori?) KPPKPP have wtm broken positions, which rather puzzles me. Ns and Ps may be colliding on squares, 'e.p.' may complicate things - I don't know. ... Collisions of pawns and pieces arise beca...

I have created the 16 missing Nalimov tablebases for `3.8 Ghz machine, but the other endings will run a lot faster. I have decided to run verification on all the endings to minimize the chances of repeated file exchanges. All the verifications were successful. Attached are the .tbs and md5sums for ...

I have created the 16 missing Nalimov tablebases for 33p endings by conversion from Johan de Koning's FEG data. The total compressed size is about 130GB, with kqpkrb being the largest at about 17GB, and kppkpp the smallest at about 1 GB. The original FEG data is about 90 GB, smaller partially becaus...