Not logged inRybka Chess Community Forum
- - By robertj (**) [gb] Date 2012-09-25 12:33 Edited 2012-09-25 13:09
In the position below Deep Rybka 4.1 first says it is mate in 11, then in 10, then in 15 (Rybka seems to stabilize claiming mate in 15). Houdini, Hiarcs and my Vafra (Crafty clone) seem to stabilize claiming mate in 14. Vafra first says it is mate in 17, then in 18, then in 13, then in 14, then in 17, then in 13, then in 14 (Vafra seems to stabilize claiming mate in 14). I used 5-men endgame tablebases. Can anybody explain why would chess engines behave like this? Thanks.

Parent - - By bob (Gold) [us] Date 2012-09-25 12:49
A program will often find a mate that is longer than optimal, because of the way the search wades through the game tree.  If you watch the various PVs, a common theme will be that when it finds a longer mate first, that mate has a lot of checking moves in the PV.  But when it finds a shorter mate, that mate will typically have more quiet (non-checking) moves, which makes it harder to find (requiring a deeper search / iteration).

A search really should NEVER report a mate shallower than what is possible.  But it can easily report one that is deeper.

When you add egtbs, you add yet another degree of freedom.  The program can't probe the tables everywhere inside the tree, so it somehow limits the depth that probes are done, and that can hide shallower mates for the same reason as above.  And it could also alter the depth in the other direction as well, when the rules on when/where to probe are somehow a little arbitrary...

In non-egtb positions, the egtb misbehavior won't be seen, but it will still report deeper mates than optimal in some positions.  A program still should never report a mate that is too short.  But the mate score can certainly bounce around higher than it should be.
Parent - - By robertj (**) [gb] Date 2012-09-25 13:02
Hello and thanks a lot for your reply professor Hyatt!

I just meant to write: "When I use brute force version of Vafra (no null-move or any other kind of forward pruning, no late move reductions, etc.) the behaviour seems to remain unchanged (maybe this behaviour is due to the usage of endgame tablebases)."

Prof Hyatt said: "A search really should NEVER report a mate shallower than what is possible.  But it can easily report one that is deeper."

It would seem that Vafra (Crafty clone) does report on few occasions a shallower mate than possible (if 14 is the shortest possible mate in the above position) as it said twice mate in 13. Deep Rybka 4.1 on the other hand reported mates in 10 and 11.
Parent - - By bob (Gold) [us] Date 2012-09-25 15:22
reporting a mate shorter than is possible is a serious bug.   Not something I see from Crafty as it would send me off to debugging to see what is wrong.  Disabling reductions and such might help, but there are still extensions.  Disabling those will tend to reduce the problem of finding a longer mate first.  Of course, the time to find mates in general is going to go up significantly.

First thing I would do is get a copy of chest, the dedicated mate-finder.  See what it says.  If it says mate in 14 is the best there is, then any program reporting a mate less than that needs to be looked at.
Parent - - By robertj (**) [gb] Date 2012-09-25 18:37
Prof Hyatt may I ask if you know how the latest Crafty behaves in this position (Black to move)? I will investigate why Crafty's clone Vafra reported mate in 13. Thanks.
Parent - - By bob (Gold) [us] Date 2012-09-25 21:16
OK.  First with 3-4-5 piece EGTBs, it finds a mate in 11.  Starts off with a mate in 16, then drops to mate in 12, then to mate in 11, and finally a mate in 10.  This is a pretty slow search because the egtbs are on a real disk, not an SSD, and the number of probes is massive.

Here's the output:

               12->  11.80  Mat16   1. f7 Kh3 2. f8=Q Kg4 3. Qg7+ Kf3 4.
                                    Qxg3+ Kxg3 <EGTB>        
               13    14.00  Mat16   1. f7 Kh3 2. f8=Q Kg4 3. Qg7+ Kf3 4.
                                    Qxg3+ Kxg3 <EGTB>        
               13->  17.97  Mat16   1. f7 Kh3 2. f8=Q Kg4 3. Qg7+ Kf3 4.
                                    Qxg3+ Kxg3 <EGTB>          (s=2)
               14    28.15  Mat12   1. f7 Kh3 2. f8=Q Kg4 3. Qc8+ Kf4 4.
                                    Bc7+ Ke3 5. Bxg3 Kf3 6. Kd3 Kxg3 <EGTB>
                                           
               14->  33.73  Mat12   1. f7 Kh3 2. f8=Q Kg4 3. Qc8+ Kf4 4.
                                    Bc7+ Ke3 5. Bxg3 Kf3 6. Kd3 Kxg3 <EGTB>
                                           
               15    41.83  Mat12   1. f7 Kh3 2. f8=Q Kg4 3. Qc8+ Kf4 4.
                                    Bc7+ Ke3 5. Bxg3 Kf3 6. Kd3 Kxg3 <EGTB>
                                           
               15->  53.88  Mat12   1. f7 Kh3 2. f8=Q Kg4 3. Qc8+ Kf4 4.
                                    Bc7+ Ke3 5. Bxg3 Kf3 6. Kd3 Kxg3 <EGTB>
                                           
               16     1:20  Mat11   1. f7 Kh3 2. f8=Q Kg4 3. Kd2 g2 4.
                                    Bb6 e1=Q+ 5. Kxe1 Kg3 6. Bc7+ Kxh4
                                    <EGTB>        
               16->   1:36  Mat11   1. f7 Kh3 2. f8=Q Kg4 3. Kd2 g2 4.
                                    Bb6 e1=Q+ 5. Kxe1 Kg3 6. Bc7+ Kxh4
                                    <EGTB>        
               17     3:32  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Be1 Kd5 6. Bxg3 <EGTB>
                                           
               17->   3:56  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Be1 Kd5 6. Bxg3 <EGTB>
                                           
               18     4:43  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Be1 Kd5 6. Bxg3 <EGTB>
                                           
               18->   5:08  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Be1 Kd5 6. Bxg3 <EGTB>
                                           
               19     7:03  Mat10   1. f7 Kf3 2. Kd3 Kg4 3. f8=Q g2 4.
                                    Kxe2 g1=N+ 5. Ke3 Kxh4 <EGTB>    
                                      
               19->   7:28  Mat10   1. f7 Kf3 2. Kd3 Kg4 3. f8=Q g2 4.
                                    Kxe2 g1=N+ 5. Ke3 Kxh4 <EGTB>    

Without tables:

               16     4.52     ++   1. f7! (>+23.99)                 
               16     4.52     ++   1. f7! (>+25.27)                 
               16     4.95     ++   1. f7! (>+27.83)                 
               16     4.95     ++   1. f7! (>+32.95)                 
               16     5.78  Mat13   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Ke5 6. Bc7+ Kf5
                                    7. h5 Kg4 8. Qg6+ Kf3 9. Qxg3+ Ke2
                                    10. Qg2+ Ke3 11. Bd6 Kd4 12. Qd2+ Kc4
                                    13. Qd3#
               16->   6.33  Mat13   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Ke5 6. Bc7+ Kf5
                                    7. h5 Kg4 8. Qg6+ Kf3 9. Qxg3+ Ke2
                                    10. Qg2+ Ke3 11. Bd6 Kd4 12. Qd2+ Kc4
                                    13. Qd3#
               17    10.20  Mat13   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Qc6+ Ka7 11. Bb6+ Ka6 12. Bd4+ Ka5
                                    13. Bc3#
               17->  10.86  Mat13   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Qc6+ Ka7 11. Bb6+ Ka6 12. Bd4+ Ka5
                                    13. Bc3#
               18    17.82  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#
               18->  19.51  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#
               19    35.75  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#
               19->  38.15  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#

               20     1:14  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#
               20->   1:19  Mat11   1. f7 Kf3 2. f8=Q+ Ke4 3. Qe7+ Kd5
                                    4. Qxe2 Kd6 5. Qa6+ Kd7 6. Bb4 Kc7
                                    7. Qd6+ Kb7 8. Ba5 g2 9. Qc7+ Ka8 10.
                                    Bb6 g1=Q 11. Qc8#

The mate in 10 looks correct.  The 2nd white move is not a promotion, note, it is a quiet king move.  If I play that against the non-table version, it sees it is a 1 move shorter mate as well.
Parent - - By robertj (**) [gb] Date 2012-09-28 22:17 Edited 2012-09-28 22:21
Prof Hyatt, it is Black's move, the position is...
8/8/5P2/B7/7P/6p1/2K1p1k1/8 b - - 0 1


Vafra without endgame tablebases first finds a 'mate in 8', then it says it is not mate...
http://www.jurjevic.org.uk/chess/vafra/temp/mate14/001.log

The line for the 'mate in 8' found by Vafra 1. ...Kf1 2. f7 e1=Q 3. Bxe1 Kxe1 4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke1 7. Kd3 g1=Q 8. Qd2+ Kf1 9. Qe2# is obviously not the shortest mate as if Black plays 4... Ke2 instead of 4... g2 consulting all-5-men endgame tablebases suggest that White cannot mate in less than 11 moves 1... Kf1 2. f7 e1=N+ 3. Bxe1 Kxe1 4. f8=Q Ke2 (4... g2 5. Qb4+ Kf1 6. Qf4+ Ke1 7. Kd3 g1=Q 8. Qd2+ Kf1 9. Qe2#) 5. Qe7+ Kf3 6. Kd3 g2 7. Qe3+ Kg4 8. Ke4 Kxh4 9. Kf5 g1=Q 10. Qxg1 Kh3 11. Kf4 Kh4 12. Qh2#.

In iterate.c in the loop...

for (; iteration_depth <= MAXPLY - 5; iteration_depth++) {
  ...
}


there was in Vafra a condition for breaking the iterative deepening loop...

for (; iteration_depth <= MAXPLY - 5; iteration_depth++) {
  ...
  if (iteration_depth > 14 && value > MATE - 300 &&
    value >= (MATE - iteration_depth - 1) && value > last_mate_score)
  break;
  ...


In Crafty 23.4 the condition is...

for (; iteration_depth <= MAXPLY - 5; iteration_depth++) {
  ...
  if (iteration_depth > 3 && value > MATE - 300 &&
    value >= (MATE - iteration_depth - 1) && value > last_mate_score)
  break;
  ...
}


I decided to remove that iterative deepening loop break from Vafra's code.

This does not fix the problem in Vafra but now Vafra without endgame tablebases finds a 'mate in 11', then a 'mate in 10', then a 'mate in 9'...
http://www.jurjevic.org.uk/chess/vafra/temp/mate14/002.log

The line for the 'mate in 11' found by Vafra 1... Kh3 2. Kd2 e1=Q+ 3. Kxe1 g2 4. Bb6 g1=Q+ 5. Bxg1 Kg2 6. f7 Kxg1 7. f8=Q Kg2 8. h5 Kg3 9. h6 Kg2 10. h7 Kg1 11. h8=Q Kg2 <TT> is obviously not the shortest mate as if Black plays 5... Kg4 instead of 5... Kg2 consulting all-5-men endgame tablebases suggest that White cannot mate in less than 12 moves 1... Kh3 2. Kd2 e1=Q+ 3. Kxe1 g2 4. Bb6 g1=Q+ 5. Bxg1 Kg4 (5... Kg2 6. f7 Kxg1 7. f8=Q Kg2 8. h5 Kg3 9. h6 Kg2 10. h7 Kg1 11. h8=Q Kg2 12. Qf2#) 6. Bc5 Kf3 7. f7 Kf4 8. f8=Q+ Ke4 9. Qd6 Kf3 10. Qe5 Kg4 11. Kf2 Kxh4 12. Kf3 Kh3 13. Qg3#. 'mate in 10' and 'mate in 9' are also likely not to be the shortest.

Vafra (version without the iterative deepening loop break) with all-5-men endgame tablebases finds a 'mate in 17', then a 'mate in 18', then a 'mate in 13', then a 'mate in 14'...
http://www.jurjevic.org.uk/chess/vafra/temp/mate14/003.log

The iterative deepening loop break will be removed from Vafra's code in version 1.2.2.
http://www.jurjevic.org.uk/chess/vafra/index.html

Prof Hyatt, may I ask? As as the iterative deepening progresses a chess engine in its non mating score search can find a better defence for Black in this position resulting in score dropping for White, can this happen for searches with mating scores resulting in longer mates for White? If it can then some of the mating lines found should not necessarily be the shortest. Am I talking nonsense here?
Parent - - By bob (Gold) [us] Date 2012-09-29 00:06 Edited 2012-09-29 00:16
That's a bug.  There is no "better defense" idea.  A forced mate is a forced mate.  If a program finds a mate that is shorter than actually possible, it certainly has a search error.  If EGTBs are involved, you might see that since the egtbs are not probed everywhere, and if you miss a probe at a key place, you can mis-evaluate.  I ran the position with NO egtbs in the second run I posted, which suggests that a mate in 10 is possible...

That old iterate escape is not very accurate today.  The thinking was, years ago, that once you found a forced mate, and you had searched deeply enough to prove there is no shorter mate, you could stop (this was done as many wanted the shortest mate, not the first mate found).  But today, with reductions and forward pruning, it takes several more plies to prove there is no shorter mate than it used to.  I've toned that exit down in my code, but it is still not perfect because reductions and forward-pruning make it impossible to know when you have searched deep enough to find the shortest mate.

But you should NEVER see a mate in N, then a mate in N+something.  That means the original mate in N was somehow wrong.  And I do not see that kind of behavior in Crafty, at least for all the games I have watched or examined.  Note that with white POV scoring, however, when searching a move for black, you CAN see a mate in 13, followed by a mate in 14 for a different move, since the mate in 14 is better for black. 

I re-ran with the right side to move.  cut and paste from your FEN string somehow overlooked the color and stuff...

all I get is mate in 14, for reasonable time limits...

               21    33.39  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=2)
               21->  46.46  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=4)
               22    49.33  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=3)
               22->   1:12  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=4)
               23     1:18  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=3)
               23->   2:14  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=3)
               24     2:23  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=2)
               24->   3:42  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=4)
               25     3:53  Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 g2 4.
                                    f8=Q+ Kxe1 <EGTB>          (s=3)
Parent - - By robertj (**) [gb] Date 2012-09-29 14:05
In the mentioned position the two lines below lead to mate for White.

Line 1: 1. ...Kf1 2. f7 e1=Q 3. Bxe1 Kxe1 4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke1 7. Kd3 g1=Q 8. Qd2+ Kf1 9. Qe2# 

Line 2: 1... Kf1 2. f7 e1=N+ 3. Bxe1 Kxe1 4. f8=Q Ke2 (4... g2 5. Qb4+ Kf1 6. Qf4+ Ke1 7. Kd3 g1=Q 8. Qd2+ Kf1 9. Qe2#) 5. Qe7+ Kf3 6. Kd3 g2 7. Qe3+ Kg4 8. Ke4 Kxh4 9. Kf5 g1=Q 10. Qxg1 Kh3 11. Kf4 Kh4 12. Qh2#

Line 2 is longer than Line 2 as in Line 1 Black had a better move (4... Ke2 rather than 4... g2).

I have a feeling that the mates found in iterative deepening iterations need not to be the shortest forced mating lines (i.e., where the best moves were played by both sides). Let us assume that neither Line 1 nor 2 lead to mate but say Line 1 to score of +10.00 and Line 2 to score of +9.25. Then Prof Hyatt I guess that you would easily accept that during an iterative deepening search a chess engine could have found first Line 1 and then Line 2, resulting in score drop for White (from +10.00 to +9.25). The fact that the scores associated with Lines 1 and 2 are mating (they are also represented with numbers) should make no difference I feel (not sure), and one may accept that during an iterative deepening search a chess engine could have found first Line 1 and then Line 2, resulting in the number of moves for White in the mating lines to increase (from 8 to 11).

Probably neither Line 1 nor Line 2 is the shortest forced (even maybe not a forced) mate (i.e. neither line does contain only the best moves for both sides) and I feel that the shortest forced mate in the position could be mate in 14 (White's moves).

I intend to implement an option in Vafra so that it can be instructed to start searching from the last iterative deepening iteration (so that only one iterative deepening iteration is going to be run) which has rather deep principal search depth set (so the search is likely never to finish unless a mate is found). The search is expected to never reach so deep to need to call the evaluation function (in Vafra, and I believe Crafty though I think not in Rybka, evaluation function is called only for leaf quiescent nodes) so if the mate is found it would be a line found by a 'perfect' search algorithm using a 'perfect evaluation function' (i.e., only mate detection) and thus the mate should be the shortest forced one (a one where both sides played the best moves). I am also able to switch off any forward pruning and late move reductions (so that the search can really be called 'perfect' brute force. I think I will make Vafra personality with these settings and save it in 'mate.cpf' file (should be available in the next release of Vafra). I will report my results (though without endgame tablebases the search in this position may last so long that I may not bother to wait for it to finish).
Parent - - By bob (Gold) [us] Date 2012-09-29 15:33
Here's the issue.  The search operates by "proving" something.  To return a mate score to the root, it has to prove that there is no escape anywhere along the PV.  And to return a mate in 10, it has to prove that there are no mates longer than 10 moves in any of those mate in 10 pathways.  Stated simply, if the program says mate in N, there must be no mates in N+something possible or else there is a bug.  yes, the search can easily find a longer mate than optimal.  And that is a pretty common occurrence.  But it should NEVER report a mate shorter than what is actually possible, because to do so, it had to prove that some line was a mate in X when it was not.  And that is a bug.

I looked through about 30 games played on ICC that I had logs for, and never found a single case of where it said mate in N and played a move, and then came back on the next move and said mate in N again or mate in N+something.  If I had such a log entry, I'd be debugging because it shows a fault in the search that needs to be fixed.  If you can screw up mates, you can also screw up backing up the right score in not  mate positions...

In your example, the program SHOULD have examined Ke2 also, and should have seen that it either did not lead to mate (if the search could not reach sufficient depth on that branch) or that it led to a longer mate, and it should have realized through its minimaxing, that the opponent would always go for the longer mate since the score is better for that side...

And for your last speculation, if a program announces mate when it is not, it is going to lose many games unnecessarily...
Parent - By robertj (**) [gb] Date 2012-09-29 21:47 Edited 2012-09-29 22:41
Prof Hyatt, implementation of a brute force search in Vafra with no iterative deepening in one deep search seems to be hopeless (and you as an experienced chess programmer may guess why, it takes ages with no output of any kind, all benefits of iterative deepening are lost, also no forward pruning of any kind, hopeless). So I will not implement that 'feature' in Vafra.

This is what I felt that it has to be true: "The mate finding procedure usually works like an ordinary depth first search. The main difference lies in the absence of the evaluation function. Mate finders only look for forced mates, but not for any material/positional advances. So any other evaluations than a mate-inspection are useless."...
http://chessprogramming.wikispaces.com/Mate+Search

If Chest chess engine is not too difficult to use (seem I will need to compile it) I may try it in this position (Chest chess engine may also take 'ages' to find the mate here)...
http://www.drb.insel.de/~heiner/Chess/chest.html
Parent - - By robertj (**) [gb] Date 2012-09-29 22:40 Edited 2012-09-29 22:43
1... Kf1 2. f7 e1=N+ 3. Bxe1 Kxe1 4. f8=Q Ke2 (4... g2 5. Qb4+ Kf1 6. Qf4+ Ke1 7. Kd3 g1=Q 8. Qd2+ Kf1 9. Qe2#) 5. Qe7+ Kf3 6. Kd3 g2 7. Qe3+ Kg4 8. Ke4 Kxh4 9. Kf5 g1=Q 10. Qxg1 Kh3 11. Kf4 Kh4 12. Qh2#

Prof Hyatt said: "In your example, the program SHOULD have examined Ke2 also, and should have seen that it either did not lead to mate (if the search could not reach sufficient depth on that branch) or that it led to a longer mate, and it should have realized through its minimaxing, that the opponent would always go for the longer mate since the score is better for that side..."

I agree with you on this one Prof Hyatt. I wonder what kind ob bug I may have in Vafra to cause such a behaviour? Then Deep Rybka 4.1 has a similar 'bug' in it, as 'she' found mate in 10 , mate in 11, etc., for some reason Rybka stabilizes on mate in 15. I wonder could it be transposition tables (as if one does nor clear transposition tables repeated search is different from the search when the tables are cleared, it would seem that Rybka keeps transposition table entries in between the searches)? Prof Hyatt, I think that mates in Crafty (and Vafra) are not handled in evaluation function, maybe something is wrong with signs (mini-max) of mate scores in the search in Vafra? Vafra with all-5-piece endgame tablebases stabilizes on mate in 14. Is this position a forced mate in 14?
Parent - - By bob (Gold) [us] Date 2012-09-30 00:06
I'm afraid to say what this position is without a lot of analysis. 

You are correct about mates, they are not part of the evaluation.  When the search realizes it searched no legal moves at some ply in the tree, AND the side on move is in check, it backs up a checkmate score...  Not sure how the sign could be confused as that would make it appear to be a mate for the other side...
Parent - - By robertj (**) [gb] Date 2012-09-30 02:53
Prof Hyatt, I think that I have the explanation. When I said that Vafra foud mate in 18, then mate in 13, then mate in 14, I referred to the search in the following Vafra log, which I guess should be OK. Vafra indeed switched from mate in 18 at the end of iteration 15 to mate in 13 in iteration 16, but at the end of iteration 16 the mate was in 14, at the end of iterations 17 and 18 the mate was again in 14, which I think is OK, as at the end of iterations we have mate in 18, mate in 14, mate in 14, mate in 14. Is this OK? Vafra sends the line to Fritz interface every time it changes its mind, so this confused me as I saw mate in 13 followed by mate in 14 not realizing that the mate in 13 was not at the end of an iteration. I think I should send to Fritz interface only lines at the end of the iterations, as Fritz can record in ChessBase online database these mid iteration lines if the search ended before the iteration has completed.

               15->  22.97 +Mat18   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf4+ Kh1 6. Qf3+ Kh2 7.
                                    Bg3+ Qxg3 <ET>
               16    25.63 +Mat13   1. ... Kh2 2. Kd2 e1=Q+ 3. Kxe1 g2
                                    4. Bb6 Kg3 5. f7 Kf3 6. f8=Q+ Ke4 7.
                                    Kf2 g1=Q+ 8. Kxg1 <ET>
               16    51.79 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               16->   2:27 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=4)
               17     2:30 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=3)
               17->   2:38 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=2)
               18     2:43 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               18->   2:43 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
Parent - - By bob (Gold) [us] Date 2012-09-30 15:45
Yes.  All of your output looks perfectly normal.  It is finding better moves at the root, delaying the mate, which is better for black.  I don't see anything unusual in your output at all...
Parent - - By robertj (**) [gb] Date 2012-10-01 15:27
Prof Hyatt wrote: "Yes. All of your output looks perfectly normal. It is finding better moves at the root, delaying the mate, which is better for black. I don't see anything unusual in your output at all..."

Thanks Prof Hyatt. That is a relief.

I believe that finding a mate in 13 below is OK?

               15->  22.97 +Mat18   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf4+ Kh1 6. Qf3+ Kh2 7.
                                    Bg3+ Qxg3 <ET>
               16    25.63 +Mat13   1. ... Kh2 2. Kd2 e1=Q+ 3. Kxe1 g2
                                    4. Bb6 Kg3 5. f7 Kf3 6. f8=Q+ Ke4 7.
                                    Kf2 g1=Q+ 8. Kxg1 <ET>
               16    51.79 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               16->   2:27 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=4)
               17     2:30 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=3)
               17->   2:38 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=2)
               18     2:43 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               18->   2:43 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>


My intention is to include "display nochanges" in the .rc file, so that the intermediate non end of iterative deepening iteration outputs are not sent to the Fritz interface. At present I am having problems in switching off the intermediate non end of iterative deepening iteration outputs in Vafra. Setting off '2' bit 'display variation when it changes' in 'display_options' seems not to work (it may be that some of that output is printed not using Print() or with a non 2 'vb' argument passed to Print(), will investigate and try to fix.)

Deep Rybka 4.1 may have a problem as she eventually 'stabilizes' claming mate in 15 (with all-5-men endgame tablebases). Houdini says (Fritz 13 Let's Check) mate in 14, Crafty and Vafra (with all-5-men endgame tablebases) eventually find mate in 14 (Vafra without the endgame tablebases managed to find only mate in 15, but maybe if it did search deeper it would have found a mate in 14).
Parent - - By bob (Gold) [us] Date 2012-10-02 01:50
Yes.  You are not finding a shorter mate than is possible.  You first find a shorter mate using move X, but then you can make it longer by playing move Y instead, at the root.  Looks correct and rational.
Parent - - By robertj (**) [gb] Date 2012-10-02 11:47
Thanks a lot Prof Hyatt!

Now Vafra (will be released in Vafra 1.2.3) displays (as a default) only output at the end of every iterative deepening iteration (the default can be changed in Fritz chess interface's 'Engine parameters' to instruct Vafra to show output every time it changes its mind).

Vafra has a 'Stockfish'-like version of singular extensions implemented. Prof Hyatt I am not sure if you would wish to glance at the Vafra's code and see if the implementation makes sense? Thanks.

http://www.jurjevic.org.uk/chess/vafra/index.html

"Singular Extensions (SE) were introduced in 1988 by Anantharaman et al. as implemented in ChipTest and Deep hought. The idea is to extend the search at expected PV- and eventually Cut-Nodes, if one move seems to be a lot better than all of the alternatives. The problem is that one does not know in advance, and therefore has to perform a reduced search with a null window lowered by some significant margin. Only if all alternatives fail below that window, a singularity is detected, and the first move is re-searched with an extended depth. While this sounds expensive, the initial publication in 1988 reported encouraging results in tactical positions. In 1991, Anantharaman re-considers SE in comparison and interaction with other extensions, and mentioned implementation issues related to the TT. A somehow relaxed version of SE was implemented in Stockfish 1.6 in 2009, restricted to moves found in the TT with a lower bound flag set. According to Larry Kaufman the idea may have its origin from Rybka 3 via the disputed open source program Ippolit or its successors." (test is for depth >= singular_depth, current value for singular_depth is 8 meaning that we consider extending if remaining depth is 8 or more plies)

My intention is to disable singular extensions in endgames. I guess this would be OK? I observed that in this position singular extensions made Vafra (with all-5-men endgame tablebases) find mate in 14 later (in 17th rather than in 16th iterative deepening iteration).
Parent - - By bob (Gold) [us] Date 2012-10-02 14:33
What stockfish does with singular extensions has absolutely nothing to do with the algorithm described in the paper you quoted.  I tested stockfish on my cluster and ran it with and without that tt-singular code, and found no difference in Elo at all.
Parent - By robertj (**) [gb] Date 2012-10-02 15:30
OK. Thanks.
Parent - By robertj (**) [gb] Date 2012-09-30 03:02
The log for search with singular extensions is similar...

               13->  25.92 +Mat18   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf4+ Kh1 6. Qf3+ Kh2 7.
                                    Qg3+ Qxg3 <TT> (s=3)
               14    26.22 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET> (s=2)
               14->  26.67 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET> (s=3)
               15    27.95 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET> (s=2)
               15->  28.56 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET>
               16    29.97 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET>
               16->  30.81 +Mat17   1. ... Kh2 2. f7 g2 3. f8=Q e1=Q 4.
                                    Bxe1 g1=Q 5. Qf2+ Kh3 6. h5 Qg4 7.
                                    Qg3+ Qxg3 <ET>
               17    36.30 +Mat13   1. ... Kh2 2. Kd2 e1=Q+ 3. Kxe1 g2
                                    4. Bc7+ Kh3 5. Kf2 g1=Q+ 6. Kxg1 <ET>
               17    52.76 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               17->   4:11 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=5)
               18     4:18 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=4)
               18->   4:27 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=2)
               19     4:35 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               19->   4:39 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET> (s=2)
               20     4:54 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               20->   4:57 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               21     5:31 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
               21->   5:32 +Mat14   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    <ET>
Parent - By robertj (**) [gb] Date 2012-09-30 03:16 Edited 2012-09-30 04:16
Log for search with singular extensions and no endgame tablebases...

               17->  50.33 +12.65   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qe7+ Kf1 6. Qf6+ Ke1
                                    7. Qe5+ Kf1 8. Qf4+ Ke2 9. Qg3 Kf1
                                    10. Qf3+ Kg1 11. h5 <TT> (s=2)
               18    52.29     +1   1. ... Kf1
               18    56.65     +3   1. ... Kf1
               18     1:45 +14.97   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf3 8. h5 Kf2 9. Qf4+ Ke1 10.
                                    Qe3+ Kf1 11. Qf3+ Kg1 12. h6 Kh1 13.
                                    Qh5+ Kg1 14. h7
               18->   3:21 +14.97   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf3 8. h5 Kf2 9. Qf4+ Ke1 10.
                                    Qe3+ Kf1 11. Qf3+ Kg1 12. h6 Kh1 13.
                                    Qh5+ Kg1 14. h7 (s=3)
               19     3:33     +1   1. ... Kf1
               19     3:36     +3   1. ... Kf1
               19     3:48     +M   1. ... Kf1
               19    28:48 +Mat11   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf1 8. Kd2 Kf2 9. h5 Kf3 10.
                                    Qh3+ Kf2 11. Qe3+ Kf1 12. Qe1# (s=2)
               19    32:54 +22.66   1. ... Kh3 2. Kd2 e1=Q+ 3. Kxe1 g2
                                    4. Bb6 Kg3 5. f7 Kf3 6. f8=Q+ Ke4 7.
                                    h5 Kd5 8. h6 Kc6 9. Qf6+ Kb5 10. h7
                                    Ka6 11. Be3+ Kb5 12. Qg5+ Kc4 13. Qxg2
               19->  35:00 +22.66   1. ... Kh3 2. Kd2 e1=Q+ 3. Kxe1 g2
                                    4. Bb6 Kg3 5. f7 Kf3 6. f8=Q+ Ke4 7.
                                    h5 Kd5 8. h6 Kc6 9. Qf6+ Kb5 10. h7
                                    Ka6 11. Be3+ Kb5 12. Qg5+ Kc4 13. Qxg2
                                    (s=3)
Parent - - By robertj (**) [gb] Date 2012-09-30 04:15
Search with no singular extensions and no endgame tablebases finds mate in 15 but not mate in 14...

               20->   2:31 +20.50   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf2 8. Kd3 Kf3 9. h5 g1=Q 10.
                                    Qxg1 Kf4 11. h6 <TT> (s=3)
               21     2:32     +1   1. ... Kf1
               21     2:33     +3   1. ... Kf1
               21     2:35     +M   1. ... Kf1
               21     3:20 +20.50   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf2 8. Kd3 Kf3 9. h5 Kg4 10.
                                    h6 Kf3 11. h7 g1=R 12. Qe2+ Kf4 13.
                                    Qf2+ Ke5 14. h8=Q+ <TT> (s=2)
               21->   3:23 +20.50   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Kf1 6. Qf4+ Ke2
                                    7. Qh2 Kf2 8. Kd3 Kf3 9. h5 Kg4 10.
                                    h6 Kf3 11. h7 g1=R 12. Qe2+ Kf4 13.
                                    Qf2+ Ke5 14. h8=Q+ <TT>
               22     3:23     +1   1. ... Kf1
               22     3:23     +3   1. ... Kf1
               22     3:24     +M   1. ... Kf1
               22     5:52 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 8. Qh2 <TT>
               22->  18:13 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 8. Qh2 <TT> (s=4)
               23    26:39 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 <TT> (s=3)
               23->  30:41 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 <TT> (s=2)
               24    45:08 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 8. Qh2 Kf2 9. h5 Kf3 10.
                                    h6 g1=Q 11. Qxg1 Ke4 12. h7 Kf4 13.
                                    h8=Q Kf5 14. Qhd4 Ke6 15. Qg6+ Ke7
                                    16. Qdd6#
               24->  50:40 +Mat15   1. ... Kf1 2. f7 e1=Q 3. Bxe1 Kxe1
                                    4. f8=Q g2 5. Qb4+ Ke2 6. Qe4+ Kf2
                                    7. Qf4+ Ke2 8. Qh2 Kf2 9. h5 Kf3 10.
                                    h6 g1=Q 11. Qxg1 Ke4 12. h7 Kf4 13.
                                    h8=Q Kf5 14. Qhd4 Ke6 15. Qg6+ Ke7
                                    16. Qdd6#
Parent - By bob (Gold) [us] Date 2012-09-30 15:43
That is not so unusual.  As I mentioned, finding a mate with several checks in the PV is much easier than finding a mate with more quiet moves in the PV.  The search will extend where there is a check, but not on quiet moves, making such mates tougher to find.

null-move can also hurt a bit since if there is a non-checking zugzwang move in the PV, null-move can cause the program to overlook that completely.
Parent - - By robertj (**) [gb] Date 2012-10-03 09:44 Edited 2012-10-03 10:31
Here is another position for you to try, Vafra (after 3 hour and 5 minute search examining 653 meaganodes on relatively modest Windows hardware reaching depth of 19 principal plies) finds a mate in 25 (I have no logs, sorry) in the final position of the game Hikaru Nakamura vs Anish Giri at the FIDE Grand Prix 2012 in London (using all-5-men endgame tablebases), Nakamura seems to be really a fighting chess player...

8/1p6/1k6/8/2PB2p1/1K1P3p/8/8 b - - 0 65
Parent - By robertj (**) [gb] Date 2012-10-05 12:43
Previous solution was with Vafra 1.2.3 where I introduced locking of the access to (Hyatt's lockless) transposition tables (I found that CPU usage drops from 100% to approximately 75% when locking the access to the tables on Windows using critical sections which should be the most efficient way of locking threads on Windows) and now I repeated it with Vafra 1.2.4 where again I do not lock the access to the transposition tables (I was worried what if there is a flaw in Hyatt's lockless algorithm, but the overhead seems to be significant, though I am not quite sure how the drop from 100% to 75% CPU usage affects meganodes figures, which though I probably should have I did not measure).

               25->   2:11  +5.36   1. ... Kc6 2. Be5 Kd7 3. Kc3 Ke6 4.
                                    d4 Kf5 5. Kd3 Kg5 6. d5 Kf5 7. Kd4
                                    b6 8. Bg3 Kf6 9. Ke4 Kg5 10. Bh2 g3
                                    11. Bxg3 Kg6 12. Bh2 Kf7 13. Bg1 Kf6
                                    14. Bxb6
               26     2:53  +5.74   1. ... Kc6 2. Be5 Kd7 3. Kc3 Ke6 4.
                                    d4 Kf5 5. Kd3 Kg5 6. d5 Kf5 7. Kd4
                                    b6 8. Bg3 Kf6 9. Ke4 Kg5 10. Ke5 Kg6
                                    11. Kf4 Kf7 12. Kxg4 Ke8 13. Kxh3 Kd7
                                    14. Kg4
               26->   3:10  +5.74   1. ... Kc6 2. Be5 Kd7 3. Kc3 Ke6 4.
                                    d4 Kf5 5. Kd3 Kg5 6. d5 Kf5 7. Kd4
                                    b6 8. Bg3 Kf6 9. Ke4 Kg5 10. Ke5 Kg6
                                    11. Kf4 Kf7 12. Kxg4 Ke8 13. Kxh3 Kd7
                                    14. Kg4
               27     3:57  +5.74   1. ... Kc6 2. Be5 Kd7 3. Kc3 Ke6 4.
                                    d4 Kf5 5. Kd3 Kg5 6. d5 Kf5 7. Kd4
                                    b6 8. Bg3 Kf6 9. Ke4 Kg5 10. Ke5 Kg6
                                    11. Kf4 Kf7 12. Kxg4 Ke8 13. Kxh3 Kd7
                                    14. Kg4 Ke7
               27->   4:05  +5.74   1. ... Kc6 2. Be5 Kd7 3. Kc3 Ke6 4.
                                    d4 Kf5 5. Kd3 Kg5 6. d5 Kf5 7. Kd4
                                    b6 8. Bg3 Kf6 9. Ke4 Kg5 10. Ke5 Kg6
                                    11. Kf4 Kf7 12. Kxg4 Ke8 13. Kxh3 Kd7
                                    14. Kg4 Ke7
               28     4:15     +1   1. ... Kc6
               28     5:32     +3   1. ... Kc6
               28     5:49     +M   1. ... Kc6
               28    27:53 +Mat28   1. ... Kc6 2. Be5 Kd7 3. Kb4 Kc6 4.
                                    d4 Kd7 5. Kb5 Ke6 6. Kb6 Kf5 7. Kxb7
                                    Kg5 8. Bg3 Kf5 9. c5 Ke4 10. c6 Kf3
                                    11. Be5 g3 12. c7 g2 13. Bh2 Kg4 14.
                                    c8=Q+ Kh4 <TT>
               28->  43:39 +Mat28   1. ... Kc6 2. Be5 Kd7 3. Kb4 Kc6 4.
                                    d4 Kd7 5. Kb5 Ke6 6. Kb6 Kf5 7. Kxb7
                                    Kg5 8. Bg3 Kf5 9. c5 Ke4 10. c6 Kf3
                                    11. Be5 g3 12. c7 g2 13. Bh2 Kg4 14.
                                    c8=Q+ Kh4 15. Qc6 <TT> (s=2)
               29   100:59 +Mat23   1. ... Kc6 2. Be5 Kc5 3. d4+ Kb6 4.
                                    Ka4 Kc6 5. Kb4 Kd7 6. d5 <TT>
               29-> 384:33 +Mat23   1. ... Kc6 2. Be5 Kc5 3. d4+ Kb6 4.
                                    Ka4 Kc6 5. Kb4 Kd7 6. d5 <TT> (s=2)
Parent - By robertj (**) [gb] Date 2012-10-05 12:48
Correction: in the post with the diagram "reaching depth of 19 principal plies" should have read "reaching depth of 29 principal plies)"
Parent - By robertj (**) [gb] Date 2012-10-05 12:55
Any other solutions? I am not sure if mate in 23 is possible with the best play for both sides or perhaps it is only a mate in 25 (if with the best play for both sides no mate in 23 is possible then Hyatt's lockless algorithm in Vafra may have a flaw in it).
Parent - By pattox [au] Date 2013-01-23 23:54
A program will often find a mate that is longer than optimal, because of the way the search wades through the game tree.  If you watch the various PVs, a common theme will be that when it finds a longer mate first, that mate has a lot of checking moves in the PV.  But when it finds a shorter mate, that mate will typically have more quiet (non-checking) moves, which makes it harder to find (requiring a deeper search / iteration).

A search really should NEVER report a mate shallower than what is possible.  But it can easily report one that is deeper.

I was recently presented with the following position

8/8/8/8/1Q6/8/kP1B2PP/6K1 w - - 0 1


Deep Rybka 4, after 5 minutes showed 10 different mates in 4 moves starting with:
either
Qc3
Qe4
Bc1
b3

Qa4
Qa5
Qc4
Bc3
Qh4
Qc5

Houdini and Strelka agree with mate in 4 with first 4 starting moves.  With the remaining 6 moves, the other 2 engines say mate in 5.  I haven't checked them all but Rybka is clearly wrong in at least the line starting with Qc5.  Rybka's mate in 4 is shown as the main line below, and Strelka's refutatation (mate in 5) is shown as a variation.

Does this indicate that Rybka has a major flaw?

[Event "?"]
[Site "?"]
[Date "2013.01.24"]
[Round "?"]
[White "New game"]
[Black "?"]
[Result "1-0"]
[SetUp "1"]
[FEN "8/8/8/8/1Q6/8/kP1B2PP/6K1 w - - 0 1"]
[PlyCount "7"]

1. Qc5 Kxb2 (1... Kb1 2. Qc4 Ka1 3. Qc2 Ka2 4. Bc3 Ka1 5. b3#) 2. Qc3+ Ka2 3.
Bc1 Kb1 4. Qb2# 1-0

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill