I agree. You have to stalemate the enemy king so that he is forced to push the pawn. But if you then capture the pawn, the king is still stalemated and the game ends.rjgibert wrote:Your example does not "count." He implicitly meant a position with white to move where white does not have an immediate axb capture and the black king is on a7, a8, b7 or b8. Other examples are not interesting.
A 2nd black pawn on b5 would sort of count. But with one 1 black b-pawn, it does not seem possible.
Position crafty and stockfish both badly mis-evaluate
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Position crafty and stockfish both badly mis-evaluate
-
- Posts: 1154
- Joined: Fri Jun 23, 2006 5:18 am
Re: Position crafty and stockfish both badly mis-evaluate
Interesting stuff. Well, we cannot have Gaviota and Critter understand this situation and Hannibal failing! I guess I need to put this position on the stack of things to solve before the next version. Perhaps it is a Quiescence search issue as you suggest...Hannibal should understand most of the transpositions but when the a pawn becomes a b pawn, it needs to catch the stalemate which may not be happening in all cases.michiguel wrote:Gaviota was supposed to know all this but this position is very tricky for other reasons.BubbaTough wrote:This position is tricky because the b pawn in some positions can be forced to advance letting white convert his 2nd a pawn into a b pawn, which will foil most evals if done near the leafs of the tree. If you made the b pawn into a pawn on any other file, I expect more programs would understand this position better.
When trying to fix things in these positions, care must be taken. This particular positions is drawn, but there are similar positions which are not.
-Sam
First of all, white can force black to take the bishop, and if the program does not recognize KPPKP with two rook pawns as draw, it will keep giving a high positive score.
Second, if there is no detection of stalemate in quies, the search can wisely direct the PV to make sure that always the last quies move is taking the b pawn with stalemate. The evaluation will be with a winning score (since the pawn now is in the "b" column).
Third, if the futility margin is not big enough in quies(), it will make the whole thing worst, particularly with an evil interaction with the hashtables. I needed to correct all this three things, and now it works:
-Sam
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: Position crafty and stockfish both badly mis-evaluate
Not perhaps. It is.Perhaps it is a Quiescence search issue as you suggest..
Once I let gnuchess check for stalemate during quiescence search the issue went away.