Blocked Position (No computer common sense)

[Don]

I have no idea where I got this position but found it in some old files I was getting rid of. It's amazing that of all the engines I tested all except Critter think that White's position is hopeless while obviously it is a dead draw.

6kr/5b1p/2p3pP/rpPp1pP1/pP1PpP2/P3P3/1K6/8 w - -

There are versions of Crafty that find this instantly. By evaluation. The problem is, how often have you seen such a position? How much will recognizing that improve a program? And most importantly, how much time does that waste in the evaluation and what is the cost in the positions where such locked pawns don't occur? Answer to the second question. It won't improve the Elo at all. The answer to the third question is "it costs quite a few Elo because it slows the NPS down and reduces the depth slightly." If you look at crafty 19.10 and a few versions after that, there is specific code (not written by myself, contributed by someone else. If you compile with -DDETECT_DRAWS it should find that instantly. Unfortunately the cost was too high and it was removed in later versions...

I think that while what you say is true, it will have to be addressed at some point in the future because in the long term it is a scalability issue. Let's pretend that computers will continue to double in speed every couple of years - at some point the program that understands "closed positions" starts to have a serious advantage. That may be the only real advantage one well written program might have over another. Few programs would purposely avoid these positions, especially the draw positions where one side appears to be up a piece or more. The program that understand this can dupe another program into losing.

Future programs might solve most of these simply with the 50 move draw rule but that doesn't help much when this appear at leaf nodes and the program thinks it has a won game. Turn a real win into one of these draws.

[Don]

I did have some code in Komodo at one time which would solve positions like this with little trouble. But strangely it was a minor performance degrade. The code was simple, if there are 8 ram pairs on the board we only use a fraction of the score. So sacrificing the rook would actually be a win in a case like that.

Code like that is subject to various problems. It is similar to square of the pawn, hard to get right because you have to cover all the exceptions. I wanted to generalize the principles but in the end this will be a big project to improve closed position handling. It's always easy to address a single position of course.

I think that 2 general principles usually come to the front with closed positions and probably several support principles. Primarily though it comes down to a willingness to make a critical pawn break and/or a sacrifice to allow progress.

You can also coerce a program via the 50 move draw rule - where you gradually push the score down to zero as more moves go by. A deep enough search will solve this simply by this rule (I think Komodo would solve it EVENTUALLY) due to this. But it's not quite the same as actually understanding what is going on.

Don

I have no idea where I got this position but found it in some old files I was getting rid of. It's amazing that of all the engines I tested all except Critter think that White's position is hopeless while obviously it is a dead draw.

6kr/5b1p/2p3pP/rpPp1pP1/pP1PpP2/P3P3/1K6/8 w - -

There are versions of Crafty that find this instantly. By evaluation. The problem is, how often have you seen such a position? How much will recognizing that improve a program? And most importantly, how much time does that waste in the evaluation and what is the cost in the positions where such locked pawns don't occur? Answer to the second question. It won't improve the Elo at all. The answer to the third question is "it costs quite a few Elo because it slows the NPS down and reduces the depth slightly." If you look at crafty 19.10 and a few versions after that, there is specific code (not written by myself, contributed by someone else. If you compile with -DDETECT_DRAWS it should find that instantly. Unfortunately the cost was too high and it was removed in later versions...

Closed positions are quite common in chess and should be reflected in a chess programs evaluation, ex. Knights are better than Bishops in closed positions!

Closed positions where one can take a rook and lose are NOT very common in chess. Most programs evaluate closed positions to some extent, just not to the extent required to not take the rook or whatever...

I think the question many might have though is exactly how many elo points are we talking about being lost by putting in that evaluation. Obviously Critter is among the very elite engines and has that programmed in. Would one need to have a special engine for different positions?