Author: Omid David
Date: 17:39:02 10/03/02
Go up one level in this thread
On October 03, 2002 at 20:29:28, Jeremiah Penery wrote:
>On October 03, 2002 at 19:39:27, Omid David wrote:
>
>>On October 03, 2002 at 19:18:16, Jeremiah Penery wrote:
>
>>>[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]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).
>>
>>However, for the first and last positions it fails to detect the draw. Your last
>
>In the first position, my original method didn't detect a draw because the
>A-File has no pawns and there is a rook/queen on the board. I now declare a
>draw if all the pawns are blocked in a certain way, regardless of remaining
>material - I figure the search can more easily find wins than it could find a
>draw otherwise.
>
>>position is really interesting; my program failed to detect the draw because of
>>the very reason you mentioned.
>
>I might try to work on this some, and come up with a solution if possible. But
>right now I'm not sure how to do it.
>
>>BTW, how much (in percentage or NPS) did the implemented draw detection slow
>>down the engine?
>
>AthlonXP 1600MHz is the hardware. I can get nearly a million NPS in bench from
>normal Crafty with a very optimized compile, but my compiles are always quite a
>bit slower for some reason, and I've implemented some probably costly functions.
> The only difference in the two benches below is the blocked-position draw
>detection.
>
>With detection:
>
>Crafty v18.15
>
>White(1): bench
>Running benchmark. . .
>......
>Total nodes: 69410117
>Raw nodes per second: 708266
>Total elapsed time: 98
>SMP time-to-ply measurement: 6.530612
>
>Without:
>
>Crafty v18.15
>
>White(1): bench
>Running benchmark. . .
>......
>Total nodes: 69410117
>Raw nodes per second: 715568
>Total elapsed time: 97
>SMP time-to-ply measurement: 6.597938
>
>It's not the most scientific thing in the world, but I think it's safe to say
>that it doesn't hurt performance all that much (especially compared to some
>other things I've implemented in the past :). If there are some specific tests
>you'd like me to run, I'd be happy to do so.
Quite impressive, just 1.02% slower (paractically negligible). Do you invoke
that detection at every node in the search tree?
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.