Ostrich tactics and pointless checks

[op12no2]

I often watch my engine's eval report a flatish value over a fair number of moves, while the opponents eval is rapidly rising; the inevitable result being a lost position, both engines are searching to similar depths (or at least appear to be). My engine is white in for example:-

[d]5k2/p7/3R4/2p3p1/1bP3P1/5N1P/3p1PK1/3r4 b - -

I think what's happening is that the bad score is being pushed over the horizon with delaying tactics - namely pointless checks - especially in positions like the above. Which is fine once you are there - but it stops you avoiding getting there as well!

Always extending checks (to counter the wasted moves) and including promotions in Q search has helped a bit, but it seems an expensive solution.

As for alternative solutions, I'm having trouble. Things like not checking unless there is another piece attacking the king zone appear to work in the above case, but it's a bit ad hoc and probably a net loss. Also the rook is wandering back to places it could have moved to originally (during the pointless checks), so that must be a clue as well (I think I read that in a HGM post) - but there again it could possibly establish a draw by 3 reps.

Is there any established theory about this sort of thing? (that I can't find).

[Stan Arts]

An evaluation thing I think. In the position you gave search has to solve a lot. The black rook can't move, white gets it's own passers on the kingside and the way to win is to push the a pawn forcing white to do something. Ofcourse that's going to take considerable depth never mind the delaying tactics.

I think evaluating the potential of the passed pawns well is key here. Maybe knowing that the white king is out of reach of the a pawn but the black king is in reach of white's passers even with several pieces left on the board is a simple term that can be used. (Let me add that to Nemeton..)

[op12no2]

OK thanks Stan. As it happens my eval is as yet primitive WRT passed pawns. This is now Lozzas analysis for the above position (a position it seems to have originally sleepwalked into) to depth 15 with the always extend and Q tweaks (without them the eval at the same depth was < 100!):-

Code: Select all

15.78 14/27 (263cp) a5 Rd5 a4 Rf5 Kg8 Rxg5 
8.09  13/25 (218cp) a5 Rd3 a4 Rd8 Ke7 Nxg5 Kxd8 Ne6 Ke7 Nxc5 Bxc5 h4 
4.45  13/25 (152cp) Ke7 Rd5 Ba5 Re5 Kd6 Rxg5 Rg1 Nxg1 d1=Q Rd5 Kc6 Rxd1 Bd2 
2.77  12/23 (152cp) Ke7 Rd5 Bc3 Rd3 Ba5 Ne5 Rg1 Kxg1 d1=Q Rxd1 Bd2 
1.9   11/23 (162cp) Ke7 Rd3 a5 Rd5 a4 Re5 Kd6 Rd5 Kc7 Nxd2 Rxd2 Rxg5 a3 
0.99  10/21 (161cp) Ke7 Rd3 Ke8 Rd5 Bc3 Nxd2 Bxd2 Rxc5 Bf4 Rd5 
0.68  9/20  (172cp) Ke7 Rd3 Ba5 Re3 Kd8 Rd3 Kc7 Rd5 Bb4 Rxd2 Bxd2 Nxd2 Rxd2 
0.42  8/17  (183cp) Ke7 Rd5 Bc3 Rxc5 Rg1 Kxg1 d1=Q Kg2 Qe2 Nxg5 
0.33  7/17  (185cp) Ke7 Rd5 Bc3 Rxc5 Re1 Nxd2 Bxd2 
0.25  6/14  (215cp) Ke7 Rd5 Bc3 Rxc5 Rg1 Nxg1 d1=Q 
0.17  5/14  (189cp) Ke7 Rd3 a6 Nxg5 Rg1 
0.09  4/11  (321cp) Ke7 Ra6 Rg1 Nxg1 d1=Q 
0.07  3/11  (315cp) Ke7 Ra6 Rg1 
0.06  2/8   (449cp) Ke7 Nxd2 

BETA 2 393 >= 393

0.04  1/7   (318cp) Rg1 
0.04  1/5   (83cp)  Kg7 
0.03  1/5   (81cp)  Ke7 

Jazz 840 (the opponent in question at the time on CCRL - thanks Graham!) has an eval of > 400 at the same depth, so better eval makes sense. Maybe I was latching on to the wrong thing... not that pointless checks aren't really annoying - but perhaps inevitable.

[Ferdy]

[d]5k2/p7/3R4/2p3p1/1bP3P1/5N1P/3p1PK1/3r4 b - -
I think it is just normal for an engine to look for perpetual check when its first attempt to get a good position fails.

Code: Select all

Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
Cores: Physical = 4, Logical = 8
Physical Memory: Total = 12 GB, Available = 8 GB

id name Deuterium v2015.1.35.169
Hash: 256 MB, Threads: 1, MultiPV: 1, AllocTime: 2.0m

FEN: 5k2/p7/3R4/2p3p1/1bP3P1/5N1P/3p1PK1/3r4 b - -

  +4.82/24  0h:01m:11s:202ms   1... a5 2. Rd5 a4 3. Rf5+ Ke7 4. Re5+ Kd6 5. Rd5+ Kc7 6. Nxd2 Rxd2 7. Rxg5 a3 8. Rg7+ Kd6 
  +3.90/23  0h:00m:12s:249ms   1... a5 2. h4 gxh4 3. g5 h3+ 4. Kg3 h2 5. Kxh2 Rf1 6. Rf6+ Kg7 7. Nxd2 Bxd2 8. Kg2 Rc1 
  +3.96/22  0h:00m:09s:096ms   1... a5 2. h4 gxh4 3. g5 h3+ 4. Kg3 h2 5. Kxh2 Rf1 6. Rf6+ Kg7 7. Nxd2 Bxd2 8. Kg2 Rc1 
  +3.84/21  0h:00m:05s:741ms   1... a5 2. h4 gxh4 3. g5 h3+ 4. Kg3 h2 5. Kxh2 Rf1 6. Rf6+ Kg7 7. Nxd2 Bxd2 8. Kg3 Rg1+ 

[ymatioun]

I also think this is driven by eval: terms like king safety and passed pawns can be used to predict checkmate and promotions way before they can be seen by search.
If your eval has those terms and your opponent's eval has not, he will let you get there, and you will see your score steadily increasing while his score will only jump up when he sees actual checkmate/promotion.

Youri.

[hgm]

This is also a very common problem in Shogi. Most games there end because you are facing an indefensible mate against you, and the engine doesn't see it because the spite checks push it over the horizon. Spite checks are very easy in Shogi, because you can drop pieces with check from the hand. And it is like you say: although delaying the loss is natural, the hurt is that it does not avoid the lost position when it stil can, when it doesn't recognize it as lost.

Normally unsound spite checks drive the score so low that the necessity to deliver them in order to prevent worse is deterrent enough. In Shogi, however, typical mates start by sacrifycing a lot of material to destroy the enemy King fortress, (which gives the opponent lots of material in hand), after which you do a move that produces a 'brink mate' (= forced mate, but not a check). The spite checks to delay that mate then merely give the material back that you sacrificed before, so they won't push the opponent below alpha before he sees the mate after running out of check drops. As a result you won't recogize the original sacrifices as a forced mate (or recognize it as a threat if you play the other side) as long as you don't actually see the mate.

Here the situation is similar, despite the fact that you did not start sacrificing anything, because the checks are safe (but pointless). It would be a real improvement if you could recognize them as pointless delay.

My idea (which I did not really test yet) is that this should be possible without excessively extending checking branches, by classifying checks as 'suspect' moves. If all non-checks end bad, but a check does not, it could be that it merely pushes the disaster seen in the non-checking branches over the horizon. Even with a check-extension a check + evasion still eat away one ply. So it is particularly important to know whether the non-checking moves could have seen the disaster with one ply less search depth. If they could, then the check should be rather harmless, because even after the delay it caused enough depth should be left to see the same problem. So if it doesn't see it, it means that the check really did change something essential.

But if the (d-1)-ply search on the non-checking moves failed high, but the d-ply search fails low, then a fail-high on the checking move is sort of predictable. Even pointless delays would produce it. So actually searching it seems counter-productive. More accurate would be to just prune it. (And this would be faster too...) If you must search it, you should extend both check and evasion to have a chance to get a reliable result. (Very expensive, and a recipe for search explosion.)

The problem of course is how to get the result of the (d-1)-ply search. You cannot do that after the d-ply search, because then hash hits would just return the result of the d-ply search. (Unless you spoilt the hash key, which is sort of wasteful). So you cannot do it after you concluded that the d-ply search on the non-checks fails low. That means you must start with a reduced search on the non-checks, as a sort of IID iteration. In a regularly expanding tree the result of such a search should be available from the previous root iteration. Indeed, it is very possible that the node itself would already have a hash hit of draft d-1 (so insufficient for the current search), and a lower score bound that would fail high against the current window. If the d-ply search on non-checks then fails low, you would know that it might be better to prune the checks. But if you did not have the hash hit, (or the window had changed so that it is no longer clear whether the (d-1)-ply search would now fail low or high), you would have to order a new (d-1)-ply search just to know if you should prune the check or not. (If there is a check amongst the moves.) This is still cheaper than extending both check and evasion, though. (As this would leave a d-ply search after the two, and there could be more than one check in the current position.) You could hope that the (d-1)-ply search in absense of a good hash moves primes the d-ply search in a useful way, recouping part of the effort.

[Evert]

Must be the evaluation of passed pawns, I don't think Jazz is particularly clever here. A healthy bonus for the d-pawn and the a-pawn should do it; advancing the latter provides a measure of progress, which is what is important here: you have to see that black's position becomes better as the a-pawn advances more.

[hgm]

The point is that you don't know how much better it has to get for black in order to make the position fail low for white. Black could have sacrificed something to get to this position from the root. E.g. white could have been greedy to snatch a Knight which his Rook, after which the black Pawn reached its current location through c3xd2, instead of playing d2xc3.

[op12no2]

I will do some experiments, thanks for the responses.