Skippers sixty memorable bugs: nr 5

[Sven]

Without LMR I also find Be7 at depth 7 and it cost less time. Yet another argument to remove LMR from Skipper. Also mate in N searches do better without LMR.

No, it is just another argument to fix your bugs in LMR and possibly other parts of your search. A correct LMR implementation will not lead to missing a trivial mate-in-few-plies in an 8/9/10 ply search of a trivial position. I would love to see some progress there ...

[op12no2]

I added more reasonable (but still primitive) LMR to the alpha beta searcher (still no check ext):-

Code: Select all

if (movesTried > 5 && !givesCheck && !inCheck && !interesting)
  R = 1;
else
  R = 0;

Interesting is: capture (inc EP), promotion and castling.

And got:-

Code: Select all

0.41 8/15 (181cp) Bxe7 g7 Kxg7 Rxe7 Kf6 Rf7 Kxf7 Qxb2 
0.29 7/14 (-195cp) Bxe7 g7 Kxg7 Rxe7 Kf6 Qa3 c1=Q 
0.25 7/14 (-410cp) Qxg2 Kxg2 b2xa1=Q Rxh7 Kg8 Rxa1 Bb6 
0.22 7/11 (-3mate) b2xa1=Q g7 Kg8 Bd5 Ne6 Bxe6 Qxd5# 
0.14 6/11 (411cp) b2xa1=Q g7 Kg8 Re8 Kxg7 Rxa1 
0.1 5/11 (509cp) b2xa1=Q Rxh7 Kg8 Bd5 Ne6 
0.1 5/11 (-122cp) c1=Q g7 Kg8 Qa2 Ne6 
0.08 5/10 (-410cp) Qxg2 Kxg2 b2xa1=Q Rxh7 Kg8 
0.04 4/10 (199cp) Qxg2 Kxg2 b2xa1=Q Rxa1 
0.03 3/10 (199cp) Qxg2 Kxg2 b2xa1=Q 
0.03 3/10 (186cp) c1=Q Rxh7 Kg8 
0.02 3/9 (175cp) b2xa1=Q Rxh7 Kg8 
0.02 2/9 (780cp) b2xa1=Q Rxa1 
0.02 1/9 (780cp) b2xa1=Q 

Note that without LMR it took twice as long. So while LMR can push the solution out and take longer (Draconian LMR), when done more reasonably it does not, and saves time; in this case half the time - even though it now has to make an extra call to isAttacked() for each move to compute givesCheck.

Reasonable LMR: ~0.5 sec.
No LMR: ~1 sec.
Draconian LMR: ~8 sec.

(to get to + value for Be7).

[op12no2]

i.e. as previously said, don't remove LMR, tweak/fix it.

[bob]

Don't know yet. Game was played with short time controls. It probably did not have enough time to get to depth 9. So search was not efficient. Might also be that under promotions cost too much time to investigate.

Code: Select all

Depth  Value   Time
  1  111770.00   0.024          60   b2a1 
  2  107970.00   0.042        1717   b2a1 e7h7 
  3  77978.00   0.065        4868   b2a1 e1a1 c5e7 
  4  81894.00   0.122       11998   b2a1 e1a1 c5e7 g6g7 
  5  50796.00   0.256       30048   b2a1 e7h7 h8g8 e1a1 c2c1 
  6  64962.00   0.402       45681   b2a1 e7h7 h8g8 e1a1 d4f3 h7h8 
  7  50796.00   0.723       91181   b2a1 e7h7 h8g8 e1a1 c2c1 a1c1 d2c1 
  8  50796.00   1.207      159907   b2a1 e7h7 h8g8 e1a1 c2c1 a1c1 d2c1 h1h2 
  9  30184.00   7.024      938628   c5e7 g6g7 h8g7 e1e7 g7f8 e7f7 f8f7 g2d5 d4e6 
 10  57376.00   10.250     1374380   c5e7 g6g7 h8g7 e1e7 g7f8 a1a3 c2c1 e7e1 f8g7 a3e7 

Something has to be broken. bxa1 leads to a mate in 3 for white. Crafty spots this with a 3 ply search in zero time... By the time Crafty is to just 5 plies the eval is -10 and heading toward black mating white.

These are the kinds of positions you should chew up and spit out. The holy grail for debugging a chess engine is to find a position with a very small depth/tree-size so that you can actually dump the whole thing and not end up with megabytes of data that is hard to analyze.

You should be able to dump this tree to a file (stop at depth=5) and see why a simple mate in 3 is getting overlooked. Once you find where you are missing a key move, you can fix it. And instantly get a lot stronger.

Here's a cute position from a recent game Crafty was playing:

[d]5k1K/7P/8/3rN3/8/8/8/8 w - - 0 1

This is a drawn position but tricky for black. With lots of zugzwang potential given a knight. I was, for unknown reasons, allowing null moves so long as the side on move had any piece (other than a pawn). Crafty actually played Nd7+ here, thinking Rxd7 was yet another way to draw (stalemate). But white plays Kf7 and it is a mate in 10 or something.

This was HARD to find because given this position, crafty plays it perfectly, instantly. But back up a couple of moves and do deep searches, and those null-move searches get stored in the hash, and come back to haunt you. Here for example:

[d]5k1K/7P/8/8/2N5/8/8/r7 w - - 0 1

Obviously white can't take the knight or it is a draw. The moves are almost forced, and letting Crafty search for 10 seconds for each black move leads to that Nd7+ loser. Once I found that I had unintentionally broken null-move search, it was a quick and easy fix. But finding it when you need two consecutive 10 second searches at 5M nodes per second, before it makes the losing Nd7+ move, and it took a LOT of digging through the trees and adding debugging output to catch EXACT hash hits and such. So the position you have should have your focused intently on fixing something that is broken but should be seen in 2-3-4-5-6 plies depending on how you deal with checks.

[bob]

Not enough time to edit... Obviously black plays Kf7 not white, white plays Nd7+...