Skippers sixty memorable bugs: nr 4

[op12no2]

I think so (forced mate). My PVS engine with no reductions or futility etc (so it should not miss anything) says the same, but obviously takes longer:-

http://op12no2.me/toys/lozza/fen.htm?e= ... 58&act=ana

As does Stockfish 5:-

http://op12no2.me/toys/lozza/fen.htm?e= ... 58&act=ana

(Stockfish 5 takes a while to initialise.)

[Henk]

Using separate mate search test skipper also gives mate in seven. It doesn't use any reductions. Even no null move. It took 19 minutes. So it should be mate in 7. See what happens if I enable reductions.

[Henk]

I think it is because of qSearch. If at depth < 0 in qSearch a king is captured it returns a mate score. But at depth 0 only captures or promotion moves were investigated. So these mate scores may not be correct.

[Sven]

Using separate mate search test skipper also gives mate in seven. It doesn't use any reductions. Even no null move. It took 19 minutes. So it should be mate in 7. See what happens if I enable reductions.

In normal search when playing a game (i.e., no special mate search), does skipper make a difference between "mate in 7" and "mate in 10", for instance? Does it know in how many plies it can mate (or get mated)? From the PGN it seems all forced mates have the same value, which would mean that Skipper never plays towards the shortest path to mate, and consequently tends to repeat previous positions that are still "forced mate in N", but with a bigger N than necessary, so actually the real mating sequence would never be played. In the position above 58...Kc4 is still won but "only" in 9 moves instead of 7 (by returning to c3 and then d2).

[Henk]

Using separate mate search test skipper also gives mate in seven. It doesn't use any reductions. Even no null move. It took 19 minutes. So it should be mate in 7. See what happens if I enable reductions.

In normal search when playing a game (i.e., no special mate search), does skipper make a difference between "mate in 7" and "mate in 10", for instance? Does it know in how many plies it can mate (or get mated)? From the PGN it seems all forced mates have the same value, which would mean that Skipper never plays towards the shortest path to mate, and consequently tends to repeat previous positions that are still "forced mate in N", but with a bigger N than necessary, so actually the real mating sequence would never be played. In the position above 58...Kc4 is still won but "only" in 9 moves instead of 7 (by returning to c3 and then d2).

Yes Skipper makes a difference between mate in 7 and mate in 9. Mate in 7 gets a higher score than mate in 9.

Looks like the mate scores given by Skipper can not be trusted.

For instance I get this output:

Code: Select all

Depth  Value   Time
  1  188305.00   0.016          31   c3b3 
  2  139153.00   0.022         166   c3c4 b3b7 
  3  141353.00   0.025         412   c3c4 b3b7 f3f2 
  4  141353.00   0.028         749   c3c4 b3b7 f3f2 b7d7 
  5  141353.00   0.038        2355   c3c4 b3a3 f3f2 a3a4 c4d5 
  6  141353.00   0.041        2880   c3c4 b3a3 f3f2 a3a4 c4d5 a4a7 
  7  9999995.00   0.084       11350   c3c4 b3a3 g3g2 h2h3 c1h1 h3g2 f3g2 
  8  9999993.00   0.102       15036   c3c4 b3d3 
  9  9999993.00   0.167       29734   c3c4 b3b1 
 10  9999993.00   0.230       43270   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 
 11  9999993.00   0.467       91277   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 b1h1 h4h5 h1h5 
 12  9999993.00   0.718      146229   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 b1h1 h4h5 h1h5 
 13  9999993.00   1.590      326325   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 b1h1 h4h5 h1h5 
 14  9999993.00   2.665      538612   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 b1h1 h4h5 h1h5 
 15  9999993.00   5.812     1087244   c3c4 b3b1 g3g2 h2h3 c1b1 h3h4 b1h1 h4h5 h1h5 

So at depth seven it says it's mate in 5. Perhaps it's caused by null move reductions and LMR. Or qSearch ?

[Sven]

So at depth seven it says it's mate in 5. Perhaps it's caused by null move reductions and LMR. Or qSearch ?

Using TT or not?

[Henk]

With TT.

[Sven]

With TT.

Have you checked whether the dubious behaviour disappears when disabling TT? If it disappears then check your mate score handling when storing/retrieving values to/from TT.

[Henk]

With TT.

Have you checked whether the dubious behaviour disappears when disabling TT? If it disappears then check your mate score handling when storing/retrieving values to/from TT.

Disabling TT does not help. I get this:

Code: Select all

Depth  Value   Time
  1  188305.00   0.013          31   c3b3 
  2  139153.00   0.020         166   c3c4 
  3  141353.00   0.024         472   c3c4 
  4  141353.00   0.029        1192   c3c4 
  5  141353.00   0.041        3206   c3c4 
  6  141353.00   0.061        7091   c3c4 
  7  266849.00   0.167       27779   c3c4 
  8  143353.00   0.344       60661   c3c2 
  9  190505.00   0.556      101337   c3c4 
 10  9999991.00   1.518      278102   c3c2 
 11  9999993.00   2.621      472611   c3c4 
 12  9999993.00   4.768      859834   c3c4 

[Sven]

With TT.

Have you checked whether the dubious behaviour disappears when disabling TT? If it disappears then check your mate score handling when storing/retrieving values to/from TT.

Disabling TT does not help. I get this:

Code: Select all

Depth  Value   Time
  1  188305.00   0.013          31   c3b3 
  2  139153.00   0.020         166   c3c4 
  3  141353.00   0.024         472   c3c4 
  4  141353.00   0.029        1192   c3c4 
  5  141353.00   0.041        3206   c3c4 
  6  141353.00   0.061        7091   c3c4 
  7  266849.00   0.167       27779   c3c4 
  8  143353.00   0.344       60661   c3c2 
  9  190505.00   0.556      101337   c3c4 
 10  9999991.00   1.518      278102   c3c2 
 11  9999993.00   2.621      472611   c3c4 
 12  9999993.00   4.768      859834   c3c4 

Why does disabling TT lead to extremely shortened (1-ply) PVs?

Apart from that, the key problem seems to be something else. Now I would disable null move and re-enable TT. QSearch should not cause this kind of problem, unless you have a bug in the in-check detection.