crafty bugs

[jwes]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

[bob]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

[jwes]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

[bob]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

[jwes]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

The problem is that after Kc2, either crafty is not even considering Bc1 or it is evaluating it with a score of worse than Mated in 4 or it would think Bc1 is a better move than a2. Stopping the search early for mate should only lead to missing a shorter mate, not to a wrong result.

[bob]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

The problem is that after Kc2, either crafty is not even considering Bc1 or it is evaluating it with a score of worse than Mated in 4 or it would think Bc1 is a better move than a2. Stopping the search early for mate should only lead to missing a shorter mate, not to a wrong result.

All it takes is an LMR reduction or a null-move search, both of which can be done in the same path (multiple times even) to hide this mate. I am not seeing a "wrong result" here. Just missing the shorter mate. Can you be more specific ? (I tried the position after Kc2 Bc1 as well)...

[jwes]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

The problem is that after Kc2, either crafty is not even considering Bc1 or it is evaluating it with a score of worse than Mated in 4 or it would think Bc1 is a better move than a2. Stopping the search early for mate should only lead to missing a shorter mate, not to a wrong result.

All it takes is an LMR reduction or a null-move search, both of which can be done in the same path (multiple times even) to hide this mate. I am not seeing a "wrong result" here. Just missing the shorter mate. Can you be more specific ? (I tried the position after Kc2 Bc1 as well)...

Crafty is missing a longer mate, not a shorter mate. Crafty that Kc2, a2 is mate in 4. Why does not crafty see that after Kc2, Bc1 is a better move for black than a2?

[bob]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

The problem is that after Kc2, either crafty is not even considering Bc1 or it is evaluating it with a score of worse than Mated in 4 or it would think Bc1 is a better move than a2. Stopping the search early for mate should only lead to missing a shorter mate, not to a wrong result.

All it takes is an LMR reduction or a null-move search, both of which can be done in the same path (multiple times even) to hide this mate. I am not seeing a "wrong result" here. Just missing the shorter mate. Can you be more specific ? (I tried the position after Kc2 Bc1 as well)...

Crafty is missing a longer mate, not a shorter mate. Crafty that Kc2, a2 is mate in 4. Why does not crafty see that after Kc2, Bc1 is a better move for black than a2?

OK, I will run the original position twice. First, without EGTBs at all:

Code: Select all

               11     0.01  Mat06   1. Kc2 Bc1 2. Kxc1 c2 3. Kxc2 a2 4.
                                    Nc6 b4 5. Na5 b3+ 6. Nxb3#
               11->   0.01  Mat06   1. Kc2 Bc1 2. Kxc1 c2 3. Kxc2 a2 4.
                                    Nc6 b4 5. Na5 b3+ 6. Nxb3#

If I play Bc1 it follows the PV as expected.

With EGTBs:

Code: Select all

                9     0.08  Mat04   1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
                                    Nb3#
                9->   0.08  Mat04   1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
                                    Nb3#

If I follow up with Bc1 it then reports a mate in 5. What happens on Bc1? I used a trace to see... and it was as I suspected. Bc1 is refuted by a null-move search as this is a zugzwang issue where black would rather not have to move at all, and the null-move allows it to do exactly that, which breaks the mate detection...

[bob]

Input this position and analyze with crafty 23.2:
[d]8/8/8/1p6/1N6/pKp5/1b6/k7 w - - 0 1
Crafty says Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bc1 4. Nb3# <HT>
Now make the move Kc2:
Now crafty says Mat05 1. ... Bc1 2. Kxc1 c2 3. Kxc2 <EGTB>
Apparently, crafty pruned a move that would postpone the mate. I assume that crafty could have pruned a move which would have allowed black to draw or win, which is scary. In the original position the analysis stops after ply 10, while after Kc2 the analysis continues indefinitely, which is useful here but seems excessive.

A very minor bug is that Test and Testepd functions do not turn off swindle mode.

I can't reproduce this here:

9-> 0.01 Mat04 1. Kc2 a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
...
Kc2
...
29 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#
29-> 0.05 Mat03 1. ... a2 2. Nc6 Ba3 3. Na5 Bb2 4.
Nb3#

Etc. with 3-4-5 piece egtbs used.

Try the position after Kc2 Bc1
[d]8/8/8/1p6/1N6/p1p5/2K5/k1b5 w - - 0 2

Here's what is happening. There are two ways to find a mate, either with the normal search or with an egtb hit. The LMR stuff reduces the depth, the opposite of what search extensions do. And some old rules ignore LMR (for example, if you find a mate in 5, there is no need to go beyond ply=9. That used to be true since we would often find deeper mates where the optimal (and shorter mate might not have more than 1 or 2 checks). But with LMR, since we reduce the search depth significantly, that old rule of searching to 2*mate_depth - 1 is no longer correct. In fact, there is no real way of knowing how deep you need to search. The simplest solution is to just search for the normal time limit and not stop when a mate is found... I'll investigate, but suspect more than a few might fall into this.

The only reason we stop when we do is to (a) make sure we find the shortest mate and (b) stop searching once we know we can't find a shorter mate so that the program doesn't look stupid searching for a mate in X for 3-4 minutes...

Crafty's code is supposed to always search for a shorter mate than the last time, but this doesn't happen in analysis mode. I was not originally using the analyze command which makes this fail, since there is no "previous search" in this mode, just one constant search so long as the program is concerned...

The problem is that after Kc2, either crafty is not even considering Bc1 or it is evaluating it with a score of worse than Mated in 4 or it would think Bc1 is a better move than a2. Stopping the search early for mate should only lead to missing a shorter mate, not to a wrong result.

All it takes is an LMR reduction or a null-move search, both of which can be done in the same path (multiple times even) to hide this mate. I am not seeing a "wrong result" here. Just missing the shorter mate. Can you be more specific ? (I tried the position after Kc2 Bc1 as well)...

Crafty is missing a longer mate, not a shorter mate. Crafty that Kc2, a2 is mate in 4. Why does not crafty see that after Kc2, Bc1 is a better move for black than a2?

Because Bc1 is refuted by a reduced-depth search (which doesn't see the mate at this depth). Once we get a mate score from the first move (black plays a2) we now have a bound, and the position after Bc1 appears good for black. We can't see the mate after Bc1 because a reduced-depth search fails high which rejects Bc1. I am not certain whether the Bc1 move gets refuted outright by a null-move search or just a reduced-depth search, as the tree is too big to look at in a short inspection...



This is simply another one of many anti-null-move positions...

[jwes]

Crafty is missing a longer mate, not a shorter mate. Crafty that Kc2, a2 is mate in 4. Why does not crafty see that after Kc2, Bc1 is a better move for black than a2?

Because Bc1 is refuted by a reduced-depth search (which doesn't see the mate at this depth). Once we get a mate score from the first move (black plays a2) we now have a bound, and the position after Bc1 appears good for black. We can't see the mate after Bc1 because a reduced-depth search fails high which rejects Bc1. I am not certain whether the Bc1 move gets refuted outright by a null-move search or just a reduced-depth search, as the tree is too big to look at in a short inspection...



This is simply another one of many anti-null-move positions...

I looked at it some more and believe I figured out what is happening. After 1. Kc2 Bc1 2 Kxc1 this position occurs
[d]8/8/8/1p6/1N6/p7/2p5/k1K5 w - - 0 3
Then the null move makes black move a2 and Nxc2 mates. What is not clear is if crafty should be trying null move here.