Ermintrude playing black, recently got itself into this position against a human player in a blitz game (6 seconds per move):
[d] r1bqr1k1/pp2bpp1/5n1p/3p2N1/3B3P/2PB1Q2/PP3PP1/R4K1R b - - 1 15
Having declined playing hxg5 for some moves, ermintrude wrongly judged it was now safe to do so, and lost a few moves later. When it played the knight capture it considered the PV to be
1. ... hxg5 2. hxg5 Ne4 3. Qh5 f6 4. Qh8+ Kf7 5. g6+ Ke6 7. Qxg7 with a score of +1.26 for black.
What it failed to consider after f6 was g6! which a human player would find very easily, and which leads to mate.
When I looked into this I realised what had happened. Ermintrude considers g6 to be a "quiet" move, and as black is a knight up at this point, the evaluation after g6 is short-circuited - no king safety check is done.
In fact, even if it had been done, it wouldn't have made any difference as the maximum value of all positional factors in the "slow eval" is only 75 centipawns and the knight capture would still have been played.
In fact the only way ermintrude could have detected the problem earlier was if it had extended the search after g6. To do this, it would have to somehow recognise that g6 is a deadly threat. The problem is that many such moves might appear to threaten the king, but only a few actually are genuine threats, so I don't do a specific king threat analysis for extensions as it is too expensive.
So I was wondering what do other people do? And how many of the other engines out there would also greedily make the capture at blitz time controls... !
An instructive problem
Moderators: hgm, Rebel, chrisw
-
- Posts: 287
- Joined: Sat Mar 11, 2006 3:19 am
- Location: Atlanta, GA
Re: An instructive problem
Buzz seems to see it. Not quite sure what makes it work but probably try check extensions, singular-reply extensions, and perhaps checks in qsearch. Also recapture extensions might work on this position.mambofish wrote:Ermintrude playing black, recently got itself into this position against a human player in a blitz game (6 seconds per move):
[d] r1bqr1k1/pp2bpp1/5n1p/3p2N1/3B3P/2PB1Q2/PP3PP1/R4K1R b - - 1 15
Having declined playing hxg5 for some moves, ermintrude wrongly judged it was now safe to do so, and lost a few moves later. When it played the knight capture it considered the PV to be
1. ... hxg5 2. hxg5 Ne4 3. Qh5 f6 4. Qh8+ Kf7 5. g6+ Ke6 7. Qxg7 with a score of +1.26 for black.
What it failed to consider after f6 was g6! which a human player would find very easily, and which leads to mate.
When I looked into this I realised what had happened. Ermintrude considers g6 to be a "quiet" move, and as black is a knight up at this point, the evaluation after g6 is short-circuited - no king safety check is done.
In fact, even if it had been done, it wouldn't have made any difference as the maximum value of all positional factors in the "slow eval" is only 75 centipawns and the knight capture would still have been played.
In fact the only way ermintrude could have detected the problem earlier was if it had extended the search after g6. To do this, it would have to somehow recognise that g6 is a deadly threat. The problem is that many such moves might appear to threaten the king, but only a few actually are genuine threats, so I don't do a specific king threat analysis for extensions as it is too expensive.
So I was wondering what do other people do? And how many of the other engines out there would also greedily make the capture at blitz time controls... !
Code: Select all
1 212 0 10 hxg5
1 212 0 40 hxg5
2 212 0 109 hxg5 Bxf6
2 212 0 269 hxg5 Bxf6
3 212 1 726 hxg5 Bxf6 Bxf6
3 212 1 1940 hxg5 Bxf6 Bxf6
4 212 3 3965 hxg5 Bxf6 Bxf6 hxg5
4 212 4 6531 hxg5 Bxf6 Bxf6 hxg5
5 129 7 15336 hxg5 hxg5 Ne4 Bxe4 dxe4
5 129 21 45391 hxg5 hxg5 Ne4 Bxe4 dxe4
6 129 26 55465 hxg5 hxg5 Ne4 Bxe4 dxe4 Qxe4
6 129 57 124035 hxg5 hxg5 Ne4 Bxe4 dxe4 Qxe4
7 24 75 169747 hxg5 hxg5 Ne4 Qh5 f6 Qh7+ Kf7 g6+ Ke6
7 24 209 482723 hxg5 hxg5 Ne4 Qh5 f6 Qh7+ Kf7 g6+ Ke6
8 -124 282 655991 hxg5 hxg5 Qd6 gxf6 Bxf6 Qh5 Kf8 Qh8+ Ke7 Re1+ Be6
8 3 618 1487489 Bg4 Qg3 Qd7 Bxf6 Bxf6 Nh7 Rac8 f3
8 3 807 1910470 Bg4 Qg3 Qd7 Bxf6 Bxf6 Nh7 Rac8 f3
9 6 1276 3045963 Bg4 Qg3 Qc8 f3 Bf5 Bxf5 Qxf5 Bxf6 Qd3+ Kg1
9 6 1806 4276445 Bg4 Qg3 Qc8 f3 Bf5 Bxf5 Qxf5 Bxf6 Qd3+ Kg1
10 6 2973 7103384 Bg4 Qg3 Qd7 Bxf6 Bxf6 Nf3 d4 Nh2 Bh5 Rc1
10 6 4053 9382479 Bg4 Qg3 Qd7 Bxf6 Bxf6 Nf3 d4 Nh2 Bh5 Rc1
11 25 5948 13828369 Bg4 Qg3 Qd7 Nf3 Nh5 Qh2 Bxf3 gxf3 Bf6 Rc1 g6
11 25 7598 17435452 Bg4 Qg3 Qd7 Nf3 Nh5 Qh2 Bxf3 gxf3 Bf6 Rc1 g6
12 22 11317 26578754 Bg4 Qg3 Qd7 Nf3 Nh5 Qh2 Bxf3 gxf3 g6 Re1 Bd6
-
- Posts: 2251
- Joined: Wed Mar 08, 2006 8:47 pm
- Location: Hattingen, Germany
Re: An instructive problem
Some may even trigger extensions by some trojan-pattern and/or switch the eval in some take-care mode...Pradu wrote: Buzz seems to see it. Not quite sure what makes it work but probably try check extensions, singular-reply extensions, and perhaps checks in qsearch. Also recapture extensions might work on this position.
Re: An instructive problem
Not quite
Ply 8 is the critical one. Both Ermintrude and Buzz complete a ply 7 search within 6 seconds, but neither completes a ply 8 search within 6 seconds. As a result the ply 8 search would be discarded because the search runs out of time, and the best move from ply 7 is used - which loses.
Ermintrude currently extends on the following conditions:
1. in_check or
2. available moves < 3 or
3. promote threat at horizon
I haven't tried a recapture extension but I'm not sure how that would help in this case, because g6 - the critical move - is not a capture. I am thinking of trying an extension just for a pawn push to the 6th/2nd rank in front of the king.
Ply 8 is the critical one. Both Ermintrude and Buzz complete a ply 7 search within 6 seconds, but neither completes a ply 8 search within 6 seconds. As a result the ply 8 search would be discarded because the search runs out of time, and the best move from ply 7 is used - which loses.
Ermintrude currently extends on the following conditions:
1. in_check or
2. available moves < 3 or
3. promote threat at horizon
I haven't tried a recapture extension but I'm not sure how that would help in this case, because g6 - the critical move - is not a capture. I am thinking of trying an extension just for a pawn push to the 6th/2nd rank in front of the king.
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: An instructive problem
Hi Vince,mambofish wrote:Ermintrude playing black, recently got itself into this position against a human player in a blitz game (6 seconds per move):
[d] r1bqr1k1/pp2bpp1/5n1p/3p2N1/3B3P/2PB1Q2/PP3PP1/R4K1R b - - 1 15
Having declined playing hxg5 for some moves, ermintrude wrongly judged it was now safe to do so, and lost a few moves later. When it played the knight capture it considered the PV to be
1. ... hxg5 2. hxg5 Ne4 3. Qh5 f6 4. Qh8+ Kf7 5. g6+ Ke6 7. Qxg7 with a score of +1.26 for black.
What it failed to consider after f6 was g6! which a human player would find very easily, and which leads to mate.
When I looked into this I realised what had happened. Ermintrude considers g6 to be a "quiet" move, and as black is a knight up at this point, the evaluation after g6 is short-circuited - no king safety check is done.
In fact, even if it had been done, it wouldn't have made any difference as the maximum value of all positional factors in the "slow eval" is only 75 centipawns and the knight capture would still have been played.
In fact the only way ermintrude could have detected the problem earlier was if it had extended the search after g6. To do this, it would have to somehow recognise that g6 is a deadly threat. The problem is that many such moves might appear to threaten the king, but only a few actually are genuine threats, so I don't do a specific king threat analysis for extensions as it is too expensive.
So I was wondering what do other people do? And how many of the other engines out there would also greedily make the capture at blitz time controls... !
Diep wants to take at ply=1 score +0.005 for black up.
at ply == 2 it fails high to Bg4 and after that never comes back to hxg5.
So evaluation solves this in Diep, not extensions nor search.
Vincent
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: An instructive problem
That would require you to be a preprocessor.Gerd Isenberg wrote:Some may even trigger extensions by some trojan-pattern and/or switch the eval in some take-care mode...Pradu wrote: Buzz seems to see it. Not quite sure what makes it work but probably try check extensions, singular-reply extensions, and perhaps checks in qsearch. Also recapture extensions might work on this position.
Diep isn't a preprocessor and solves this by leaf evaluation at ply==2.
Vincent
Re: An instructive problem
Hi Vincent
That's impressive to reject hxg5 at ply 2!
Does Diep always perform static analyis at each node, regardless of material score?
That's impressive to reject hxg5 at ply 2!
Does Diep always perform static analyis at each node, regardless of material score?
-
- Posts: 10444
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: An instructive problem
Movei has no problem to see it
It seems that the problem is with your static evaluation and the main line
1...hxg5 2.hxg5 Ne4 3.Qh5 f6 4.Qh8+ Kf7 5.g6+ Ke6 6.Qxg7 simply should be evaluated as better for white relative to the alternative
I am not impressed by vincent's claims that diep solves it at depth 2 by static evaluation.
We do not know if it solves it because of good evaluation or because of bad evaluation that can cause diep also to play often wrong sacrifices.
New game
r1bqr1k1/pp2bpp1/5n1p/3p2N1/3B3P/2PB1Q2/PP3PP1/R4K1R b - - 0 1
Analysis by Movei00_8_403:
1...hxg5
-+ (-1.92) Depth: 1 00:00:00
1...hxg5 2.hxg5
-+ (-1.92) Depth: 2 00:00:00
1...hxg5 2.hxg5
-+ (-1.92) Depth: 2 00:00:00
1...hxg5 2.hxg5
-+ (-2.22) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4
-+ (-2.25) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4
-+ (-2.25) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4 3.Qf4
-+ (-2.35) Depth: 4 00:00:00
1...hxg5 2.hxg5 Bg4 3.Qf4
-+ (-2.35) Depth: 4 00:00:00
1...hxg5 2.hxg5
-+ (-2.05) Depth: 5 00:00:00
1...hxg5 2.hxg5
µ (-1.35) Depth: 5 00:00:00
1...hxg5 2.hxg5 Ne4 3.Bxe4 dxe4
µ (-0.96) Depth: 5 00:00:00
1...hxg5 2.hxg5 Ne4 3.Bxe4 dxe4
µ (-0.96) Depth: 5 00:00:00
1...hxg5 2.hxg5
µ (-1.26) Depth: 6 00:00:00 14kN
1...hxg5
³ (-0.66) Depth: 6 00:00:00 16kN
1...hxg5
³ (-0.66) Depth: 6 00:00:00 32kN
1...hxg5 2.hxg5
³ (-0.36) Depth: 7 00:00:00 38kN
1...hxg5 2.hxg5 Ne4 3.Qh5 f6 4.Qh8+ Kf7 5.g6+ Ke6 6.Qxg7
= (0.02) Depth: 7 00:00:00 44kN
1...b6 2.Nh3
= (0.01) Depth: 7 00:00:00 76kN
1...b6 2.Bh7+ Kf8 3.Bd3 Kg8
= (0.00) Depth: 7 00:00:00 104kN
1...Bg4 2.Qg3
= (-0.01) Depth: 7 00:00:00 134kN
1...Bg4 2.Qg3
³ (-0.30) Depth: 7 00:00:00 142kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Bd6 4.Ne5 Qa4
³ (-0.34) Depth: 7 00:00:00 156kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Bd6 4.Ne5 Qa4
³ (-0.34) Depth: 7 00:00:00 171kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bf5 5.Be2
³ (-0.44) Depth: 8 00:00:00 204kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bf5 5.Be2
³ (-0.44) Depth: 8 00:00:01 249kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Rac8
³ (-0.56) Depth: 9 00:00:01 319kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Rac8
³ (-0.56) Depth: 9 00:00:01 405kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Bf6 6.Bc5
³ (-0.58) Depth: 10 00:00:02 536kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Bf6 6.Bc5
³ (-0.58) Depth: 10 00:00:03 849kN
(Uri, MyTown 30.05.2007)
It seems that the problem is with your static evaluation and the main line
1...hxg5 2.hxg5 Ne4 3.Qh5 f6 4.Qh8+ Kf7 5.g6+ Ke6 6.Qxg7 simply should be evaluated as better for white relative to the alternative
I am not impressed by vincent's claims that diep solves it at depth 2 by static evaluation.
We do not know if it solves it because of good evaluation or because of bad evaluation that can cause diep also to play often wrong sacrifices.
New game
r1bqr1k1/pp2bpp1/5n1p/3p2N1/3B3P/2PB1Q2/PP3PP1/R4K1R b - - 0 1
Analysis by Movei00_8_403:
1...hxg5
-+ (-1.92) Depth: 1 00:00:00
1...hxg5 2.hxg5
-+ (-1.92) Depth: 2 00:00:00
1...hxg5 2.hxg5
-+ (-1.92) Depth: 2 00:00:00
1...hxg5 2.hxg5
-+ (-2.22) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4
-+ (-2.25) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4
-+ (-2.25) Depth: 3 00:00:00
1...hxg5 2.hxg5 Bg4 3.Qf4
-+ (-2.35) Depth: 4 00:00:00
1...hxg5 2.hxg5 Bg4 3.Qf4
-+ (-2.35) Depth: 4 00:00:00
1...hxg5 2.hxg5
-+ (-2.05) Depth: 5 00:00:00
1...hxg5 2.hxg5
µ (-1.35) Depth: 5 00:00:00
1...hxg5 2.hxg5 Ne4 3.Bxe4 dxe4
µ (-0.96) Depth: 5 00:00:00
1...hxg5 2.hxg5 Ne4 3.Bxe4 dxe4
µ (-0.96) Depth: 5 00:00:00
1...hxg5 2.hxg5
µ (-1.26) Depth: 6 00:00:00 14kN
1...hxg5
³ (-0.66) Depth: 6 00:00:00 16kN
1...hxg5
³ (-0.66) Depth: 6 00:00:00 32kN
1...hxg5 2.hxg5
³ (-0.36) Depth: 7 00:00:00 38kN
1...hxg5 2.hxg5 Ne4 3.Qh5 f6 4.Qh8+ Kf7 5.g6+ Ke6 6.Qxg7
= (0.02) Depth: 7 00:00:00 44kN
1...b6 2.Nh3
= (0.01) Depth: 7 00:00:00 76kN
1...b6 2.Bh7+ Kf8 3.Bd3 Kg8
= (0.00) Depth: 7 00:00:00 104kN
1...Bg4 2.Qg3
= (-0.01) Depth: 7 00:00:00 134kN
1...Bg4 2.Qg3
³ (-0.30) Depth: 7 00:00:00 142kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Bd6 4.Ne5 Qa4
³ (-0.34) Depth: 7 00:00:00 156kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Bd6 4.Ne5 Qa4
³ (-0.34) Depth: 7 00:00:00 171kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bf5 5.Be2
³ (-0.44) Depth: 8 00:00:00 204kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bf5 5.Be2
³ (-0.44) Depth: 8 00:00:01 249kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Rac8
³ (-0.56) Depth: 9 00:00:01 319kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Rac8
³ (-0.56) Depth: 9 00:00:01 405kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Bf6 6.Bc5
³ (-0.58) Depth: 10 00:00:02 536kN
1...Bg4 2.Qg3 Qd7 3.Nf3 Nh5 4.Qh2 Bxf3 5.gxf3 Bf6 6.Bc5
³ (-0.58) Depth: 10 00:00:03 849kN
(Uri, MyTown 30.05.2007)
Re: An instructive problem
Hi Uri
First of all thanks for taking the time to check what your engine is doing and for your comments.
I am sure that you are right that my static evaluation can be improved, but unless I am misunderstanding something, I'm not sure how much this would help in this case because I don't think movei understands the position at ply 7 any more than ermintrude does
Let me explain what I mean.
At ply 7 movei scores the variation commencing 1...hxg5 2.hxg5 Ne4 3.Qh5 f6 as a negligible advantage to white. However this is entirely incorrect because white actually has a forced mate in all lines!
But movei is saved from embarrassment because at ply 7, its evaluation of the position resulting from 1 ...hxg5 line is less than the one resulting from 1 ...Bg4. Well, movei is correct in its assessment but only by luck not by an accurate evaluation of the position! (Yes, its more accurate than ermintrude, but its still way off )
Of course after having made the decision at ply 7 that Bg4 is the best move, movei's searches at deeper plies merely confirm it. (An 8 ply search is enough to refute all variations in the hxg5 line entirely).
So I believe that movei probably suffers from the same "blindness" to the quiet and winning 4 g6! in this line as ermintrude does...
What I am looking for therefore is a way to identify in a generic manner just how dangeroues 4 g6! really is. And some kind of extension would seem to fit the bill. Unfortunately, just like U2 I still haven't found what I'm looking for
First of all thanks for taking the time to check what your engine is doing and for your comments.
I am sure that you are right that my static evaluation can be improved, but unless I am misunderstanding something, I'm not sure how much this would help in this case because I don't think movei understands the position at ply 7 any more than ermintrude does
Let me explain what I mean.
At ply 7 movei scores the variation commencing 1...hxg5 2.hxg5 Ne4 3.Qh5 f6 as a negligible advantage to white. However this is entirely incorrect because white actually has a forced mate in all lines!
But movei is saved from embarrassment because at ply 7, its evaluation of the position resulting from 1 ...hxg5 line is less than the one resulting from 1 ...Bg4. Well, movei is correct in its assessment but only by luck not by an accurate evaluation of the position! (Yes, its more accurate than ermintrude, but its still way off )
Of course after having made the decision at ply 7 that Bg4 is the best move, movei's searches at deeper plies merely confirm it. (An 8 ply search is enough to refute all variations in the hxg5 line entirely).
So I believe that movei probably suffers from the same "blindness" to the quiet and winning 4 g6! in this line as ermintrude does...
What I am looking for therefore is a way to identify in a generic manner just how dangeroues 4 g6! really is. And some kind of extension would seem to fit the bill. Unfortunately, just like U2 I still haven't found what I'm looking for
-
- Posts: 10444
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: An instructive problem
I did not check it but I believe that ply 7 could be enough to see that g6 is good with no pruning because movei has checks inside the qsearch
The critical line is
hxg5 hxg5
Ne4 Qh5
f6 g6
black move Qh8 mate
After black moves it is the end of the 7 plies and now at depth 7 with no pruning it should see Qh8 mate in the qsearch.
Movei does pruning based on evaluation and remaining depth so I suspect that it may simply prune after
hxg5 hxg5
Ne4 Qh5
f6 g6
without calculating black moves at all.
Uri
The critical line is
hxg5 hxg5
Ne4 Qh5
f6 g6
black move Qh8 mate
After black moves it is the end of the 7 plies and now at depth 7 with no pruning it should see Qh8 mate in the qsearch.
Movei does pruning based on evaluation and remaining depth so I suspect that it may simply prune after
hxg5 hxg5
Ne4 Qh5
f6 g6
without calculating black moves at all.
Uri