Mate in 73

[Kirill Kryukov]

We now have a mate in 73 moves on 4x4 board with 10 pieces! This is a large and unexpected jump of +14 moves compared to 9 pieces, as maxDTM increased slowly from 6 to 9 pieces (52, 54, 56, 59 moves).

[d]b1p1/N1Pk/PBb1/BK2 w - - 0 1

You can see it in the oracle:
https://calc.biokirr.com/4x4c/query?met ... k/PBb1/BK2
(Let me know if you'll hit any missing tables while exploring).

Previously John reported maxDTM of 72 moves in the same endgame. I thought about where the difference of 1 move may come from, and so far I have only one hypothesis. I think John's statistics was for positions actually stored in the tables, but my solver does not store positions under contact check. I guess that all wins in 73 are under such checks, so they are not stored and not reported in the quick stats. The complete statistics (much slower to compute) should probably include them. I haven't computed any stats for 10 piece DTM yet, hopefully we can confirm this later.

The above position is a win. The longest line is still one ply longer, a loss in 73, e.g., the same position with black to move and bishop on d1.

[jkominek]

Nice! The positions is fun to play through. Not that I can comprehend any plan, through.

In working with your program I could tell that you do not store all positions in the tables but instead perform a search of dependent tables for a certain subset, such as checks. Similar to syzygy, individual files are not independent. Seems to me you made a design choice to optimize file size over access speed.

The stats files I generated do have me confused, because I believe I did generate them using the slower "real stats" mode. In the Nalimov naming convention you'd have a pair of files, kbbnpp-kbbp.wtm and kbbnpp-kbbp.btm file extensions (adding a hyphen for readability). This pair is accompanied with one stats file. Win in X moves are odd-ply paths, while Loss in X moves are even-ply paths, for wtm and btm respectively. I'll admit that in my head I voice wtm as "white to move" and btm as "black to move", but what is meant is majority-side-to-move and minority-side-to-move.

In your scheme there are two stats reports available for a given piece "constellation" as hgm would call it.

In the file I shared called 4x4c_dtm_stats_real.10men there is a Loss in 73: entry with the minor side kbbp on move.

Code: Select all

=========== kbbp-kbbnpp ===========
...
Win in  45:             5 (  0.00%)
Win in  46:            12 (  0.00%)
Win in  47:            11 (  0.00%)
Win in  48:             2 (  0.00%)
Draw:            50086040 ( 36.47%)
Loss in  73:            2 (  0.00%) [annotation: loss in 146 ply]
Loss in  72:            2 (  0.00%) [annotation: loss in 144 ply]
Loss in  71:            7 (  0.00%)
Loss in  70:           11 (  0.00%)

Now referencing the mirror table with major side kbbnpp on move we have:

Code: Select all

=========== kbbnpp-kbbp ===========
...
Win in  70:            10 (  0.00%)
Win in  71:            22 (  0.00%)  [annotation: win in 141 ply]
Win in  72:            11 (  0.00%)  [annotation: win in 143 ply]
Draw:             5892264 (  4.29%)
Loss in  37:            4 (  0.00%)
Loss in  36:            5 (  0.00%)
Loss in  35:            7 (  0.00%)

If you'll excuse the turn of phrase are we looking at a missing entry for a kbbnppkbbp Win in 73? In the position you posted white plays first, i.e. the majority side plays first.

[Kirill Kryukov]

Nice! The positions is fun to play through. Not that I can comprehend any plan, through

The line is kind of insane if you ask me, but I still need to understand it better. I lost count of how many times the white king does the triangle maneuver here, intersting to see it repeated again and again.

In working with your program I could tell that you do not store all positions in the tables but instead perform a search of dependent tables for a certain subset, such as checks. Similar to syzygy, individual files are not independent. Seems to me you made a design choice to optimize file size over access speed.

Something like that, although it's still far from optimal. I.e., now there is no speed, but it's still far from being as compact as it should be.

The stats files I generated do have me confused, because I believe I did generate them using the slower "real stats" mode.

Yes, this is my fault entirely. You will probably not believe what I'm going to say, but "real" the fast mode, counting only positions actually stored on disk. (You can easily confirm this by timing the two stat-generating options, as well as by comparing their outputs). I think at the time I thought of actually stored positions as "real", and the rest were "imaginary". At some point I realized that this was an unfortunate choice (probably after getting confused myself), and changed "real" to "stored" in the interface.

In the Nalimov naming convention you'd have a pair of files, kbbnpp-kbbp.wtm and kbbnpp-kbbp.btm file extensions (adding a hyphen for readability). This pair is accompanied with one stats file. Win in X moves are odd-ply paths, while Loss in X moves are even-ply paths, for wtm and btm respectively. I'll admit that in my head I voice wtm as "white to move" and btm as "black to move", but what is meant is majority-side-to-move and minority-side-to-move.

In your scheme there are two stats reports available for a given piece "constellation" as hgm would call it.

Yeah, I generally produce a stat file for each ESM (endgame + side to move). Pairs of them can then be combined into endgame stat reports (for non-symmetrical material).

In the file I shared called 4x4c_dtm_stats_real.10men there is a Loss in 73: entry with the minor side kbbp on move.

Yes, I should have noticed this earlier. A loss in 73 indicates that there must be a win in 73 too! (Because the loss is 1 ply longer).

If you'll excuse the turn of phrase are we looking at a missing entry for a kbbnppkbbp Win in 73? In the position you posted white plays first, i.e. the majority side plays first.

I think the current theory is consistent with all data. Your stats include only positions stored on disk, and all wins in 73 are probably not stored because of being in check.

Sorry, I still haven't looked closely at your stats, because I still have nothing to compare them with. After 10-piece generation run is complete, I will try to generate the stats (both stored and complete), and then hopefully can get more confirmation.