Author: Omid David
Date: 03:26:13 10/04/02
Go up one level in this thread
On October 04, 2002 at 04:10:01, Uri Blass wrote:
>On October 03, 2002 at 19:39:27, Omid David wrote:
>
>>On October 03, 2002 at 19:18:16, Jeremiah Penery wrote:
>>
>>>8/7p/6pP/k4pP1/b1p1pP2/KpPpP3/1P1P4/7Q w - - 0 1
>>>3k4/2p1p1p1/p1P1P1Pp/P6P/4K3/8/8/8 w
>>>8/4kr1b/4p3/rp1pPp1p/pPpP1PpP/P1P3P1/2K5/8 w
>>>8/4k3/8/p1p1p1p1/P1P1P1P1/8/2B1K3/8 w
>>>4b3/4k3/2p1p1p1/1pPpPpPp/pP1P1P1P/P2K4/3B4/8 w - - 0 1
>>>3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P1K2P/PPB5/8 w - - 0 1
>>>4k3/8/1p1p4/pPpPp1p1/P1P1PpPp/5P1P/2BB4/K7 w
>>>
>>>
>>>This is a set of positions that most chess programs completely don't understand
>>>because the position is completely blocked. I have implemented some ability in
>>>Crafty to understand this type of position, with decent results. There are also
>>>a couple of interesting problems that have come up, particularly with the last
>>>position.
>>>
>>>[D]8/7p/6pP/k4pP1/b1p1pP2/KpPpP3/1P1P4/7Q w - - 0 1
>>>
>>>Static evaluation is now 0 here. The solution is supposed to be Qd1 <bishop
>>>move> {Kb5 Qh5!} Qxb3. The problem in solving this is that the evaluation after
>>>the given line is negative for white, so it doesn't want to play the
>>>'sacrifice'. But I consider it a good result that it knows this is a draw since
>>>it can't make progress.
>>>Normal Crafty 18.15 says near +5, while making the wrong move.
>>>
>>>[D]3k4/2p1p1p1/p1P1P1Pp/P6P/4K3/8/8/8 w
>>>
>>>Static evaluation 0, search returns instant 60 plies with drawscore.
>>>Normal Crafty says +1.4 or so.
>>>
>>>[D]8/4kr1b/4p3/rp1pPp1p/pPpP1PpP/P1P3P1/2K5/8 w
>>>
>>>Static 0 again, search says the same.
>>>Normal crafty has static score near -13, and wants to open the position, search
>>>score keeps dropping.
>>>
>>>[D]8/4k3/8/p1p1p1p1/P1P1P1P1/8/2B1K3/8 w
>>>
>>>Drawscore, static and by 60 ply search.
>>>Normal Crafty gives +3.3 for both.
>>>
>>>[D]4b3/4k3/2p1p1p1/1pPpPpPp/pP1P1P1P/P2K4/3B4/8 w - - 0 1
>>>
>>>Static score 0, instant 60 plies.
>>>Normal Crafty is similar, +0.09/+0.06
>>>
>>>[D]3B4/1r2p3/r2p1p2/bkp1P1p1/1p1P1PPp/p1P1K2P/PPB5/8 w - - 0 1
>>>
>>>Static evaluation of -5.93 here, but it finds the draw by search in 6 plies.
>>>Normal Crafty says -6.07, and wants to open the position by search, with
>>>dropping score.
>>>
>>>[D]4k3/8/1p1p4/pPpPp1p1/P1P1PpPp/5P1P/2BB4/K7 w
>>>
>>>This is the first problem position. It is evaluated statically as a draw, but
>>>once White sacrifices its dark-squared bishop for one of black's pawns, it no
>>>longer gets evaluated as a draw. No problem, right? Well, it keeps pushing it
>>>back into the horizon:
>>>
>>> 6 0.01 6.39 1. Bxa5 bxa5 2. Kb2 Ke7 3. Kc3 Kd7
>>> 6-> 0.02 6.39 1. Bxa5 bxa5 2. Kb2 Ke7 3. Kc3 Kd7
>>> 7 0.02 6.50 1. Bxa5 bxa5 2. Kb2 Ke7 3. Kc3 Kd7
>>> 4. Kd3
>>> 7-> 0.03 6.50 1. Bxa5 bxa5 2. Kb2 Ke7 3. Kc3 Kd7
>>> 4. Kd3
>>> 8 0.03 -- 1. Bxa5
>>> 8 0.03 0.00 1. Bxa5 bxa5 2. Kb2 Kd7 3. Bb3 Kc7
>>> 4. Kc3 Kb6
>>> 8 0.04 6.39 1. Ka2 Kd7 2. Kb2 Kc7 3. Bc3 Kb7 4.
>>> Bxe5 dxe5
>>> 8 0.05 6.50 1. Kb2 Kd7 2. Kc3 Kc7 3. Kd3 Kd7 4.
>>> Bxa5 bxa5 <HT>
>>> 8-> 0.05 6.50 1. Kb2 Kd7 2. Kc3 Kc7 3. Kd3 Kd7 4.
>>> Bxa5 bxa5 <HT>
>>> .......................................................
>>> 19 2.69 6.56 1. Kb2 Kd7 2. Kc3 Kc7 3. Kd3 Kd7 4.
>>> Bc3 Ke7 5. Bb3 Kd7 6. Be1 Kc7 7. Ba2
>>> Kd7 8. Bc3 Ke7 9. Bxe5 dxe5 10. Bb3
>>> 19-> 3.05 6.56 1. Kb2 Kd7 2. Kc3 Kc7 3. Kd3 Kd7 4.
>>> Bc3 Ke7 5. Bb3 Kd7 6. Be1 Kc7 7. Ba2
>>> Kd7 8. Bc3 Ke7 9. Bxe5 dxe5 10. Bb3
>>>
>>>No matter how deep I let it go, it always pushes the bishop sac into the last
>>>couple of plies. Is there any way I can solve this problem?
>>>Normal Crafty here says 7.77 static, and it doesn't have any captures in the
>>>search as long as it goes, score stays around 8.26.
>>>
>>>Does anyone have more positions they'd like me to try, or has anyone else worked
>>>on this kind of thing in their engine?
>>
>>
>>My under-development engine, detects the positions you mentioned as draw based
>>on static evaluation (seems that you have done something similar).
>
>I think that you did something better.
>
>Based on positions that wereposted here in the past you do not need all the
>pawns to be blocked to detect a draw.
>The only question is if there are cases when your draw detection can be wrong.
>
>If it cannot be wrong then I think that doing it only when the remaining depth
>is big enough can be an advantage.
That's right, if a general "goal-oriented" blockade exists, my algorithms with
detect it (without any risk of mistakes). However its being an algorithm rather
than a simple static evaluation, results in its being too expensive to conduct
at all nodes. However, I believe a wise distribution of it along the search
tree, will make it profitable.
>
>Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.