A|H pawn && wrong bishop v K

[Ferdy]

Run up to depth 44, and it displayed -280cp for the last couple of depths, even though the pv is showing repeats.

Code: Select all

273.25 44/53 (-280cp) Kb2 Kg2 Ka3 Bb3 Kb2 Kf3 Ka3 Ke3 Kb2 Kd2 Kb1 a3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 Bd5 Kb1 Bb3 Ka1 

[hgm]

Depends what % correct you want to be. if you can accept both some false-draws and false-wins that take a couple ply of search to resolve correctly the rules for that are pretty well codified in books.

OK, thanks. The distance rule to the key squares given by Ferdinand summarizes this quite compactly, and makes it very easy to test.

I can accept some false wins, but no false draws, as the idea of the recognizer is that it immedialy prunes the branch with a hefty reduction factor when it detects a draw. False wins just keep the naive eval score of +8 and will search on, and presumably will then quickly see that a draw position can be forcibly reached.

The test is not done in the root, so in a drawn situation it will do one of the moves that preserves the draw, without caring which. The idea is that in situations like this (KPK, KBPK, KQKP) the defending side cannot possibly achieve anything more than a draw, so any drawing move is good enough. You don't want the strong side to needlessly give away its material; KBPK is better than KK w.r.t. the possibility of the defende making a mistake. (E.g. if it is an engine that doesn't know about under-promotion!) If the position is a win, however, you cannot just do any move that keeps the win, but you must work to make progress. It would be needlessly complex (and very bug prone) to let the recognizer define progress, the naive eval should be much better at that. (Or you'd better tune it!)

So I am afraid that when I use these distance rules, I will really have to test for the discovered check if the King is just one step further away then the win zone.

[hgm]

Which makes me think search is broken...!

Well, the PV is OK; it keeps the draw as it should. The score is no good however. So it seems the recognizer is somehow broken.

Note that in my case the PV would never be more than 2 moves, as the recognizer prunes in case of draw:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
 28	 -1.26 	542      	0:00.01	a1b2 a4a3
 27	 -1.26 	522      	0:00.01	a1b2 a4a3
 26	 -1.26 	502      	0:00.01	a1b2 a4a3
 25	 -1.26 	482      	0:00.01	a1b2 a4a3
 24	 -1.26 	462      	0:00.01	a1b2 a4a3
 23	 -1.26 	442      	0:00.01	a1b2 a4a3
 22	 -1.26 	422      	0:00.01	a1b2 a4a3
 21	 -1.26 	402      	0:00.01	a1b2 a4a3
 20	 -1.26 	382      	0:00.01	a1b2 a4a3
 19	 -1.26 	362      	0:00.01	a1b2 a4a3
 18	 -1.26 	342      	0:00.01	a1b2 a4a3
 17	 -1.26 	322      	0:00.01	a1b2 a4a3
 16	 -1.26 	302      	0:00.01	a1b2 a4a3
 15	 -1.26 	282      	0:00.01	a1b2 a4a3
 14	 -1.26 	262      	0:00.01	a1b2 a4a3
 13	 -1.26 	242      	0:00.01	a1b2 a4a3
 12	 -1.26 	222      	0:00.01	a1b2 a4a3
 11	 -1.26 	202      	0:00.01	a1b2 a4a3
 10	 -1.26 	182      	0:00.01	a1b2 a4a3
  9	 -1.26 	162      	0:00.01	a1b2 a4a3
  8	 -1.26 	142      	0:00.01	a1b2 a4a3
  7	 -1.26 	122      	0:00.01	a1b2 a4a3
  6	 -1.26 	102      	0:00.01	a1b2 a4a3
  5	 -1.26 	84        	0:00.01	a1b2 a4a3
  4	 -1.26 	64        	0:00.01	a1b2 a4a3
  3	 -1.26 	44        	0:00.01	a1b2 a4a3
  2	 -1.26 	21        	0:00.01	s=1, phase=1, w=1 b=1 mm=1973580320 hm=2686600 ms=0 hs=2686460 P=ffdb a1b2 a4a3
  1	 -4.40 	4          	0:00.01	a1b2

(I guess the score is a bit high, because I only divide it by 4. I really should make it a hard 0.)

[kbhearn]

A potential problem position if false-draws are a problem (two steps outside the regular win zone):

[d]1Q6/2K5/8/8/8/8/p7/k7 w - - 0 1

1. Kb6! wins as black is forced to move into a discovered check, and then white gets into the win zone with the move.

In general the black king blocking the pawn also extends the win zone - though in the case of a c-pawn white will usually use the move to play the queen to the b-file and get the larger long-side win zone.

[hgm]

Indeed, being in front of the Pawn should be penalized by a larger win zone, or perhaps not recognized at all. There never is a reason to step in front, except with c/f on the long side. And next move you will always step away again, to a recognized draw, so a 2-ply search should always be enough to see the draw.

In theory you could make a recognizer that says prune/extend/nothing, and extend the dubious cases when you are sure they will resolve quickly, so that in the event they do draw, you will still see it at the lowest depth.

[op12no2]

Run up to depth 44, and it displayed -280cp for the last couple of depths, even though the pv is showing repeats.

Yeah I don't trust my PV as far as I can throw it - it gets into TT loops. I think tomorrow's job will be to go back to the old non TT way I used to it.

I tweaked my search to differentiate between score == 0 computed and 0 recognised as a draw and return immediately if the latter after reading HGMs post (I call eval() in every node). Why search further if one can accurately evaluate the board.