Author: Robert Hyatt
Date: 20:13:14 08/20/04
Go up one level in this thread
On August 20, 2004 at 22:36:17, Michael Henderson wrote:
>On August 20, 2004 at 17:16:24, Rick Bischoff wrote:
>
>>Hello all,
>>
>>I just recently started rewriting my engine after a year or so break. I was
>>currently testing a position that is a known draw-- and my search was returning
>>a score of +3 pawns for white (white has a rook, black has a pawn on the 7th).
>>
>>[D]R7/8/8/8/3K4/8/3kp3/8 w
>>
>>So I took the following steps to remedy the situation:
>>
>>1. I should probably test to see if my draw by repetition function is working
>>correctly and in all cases. It is, ok...
>>
>>2. Ok.. Maybe I should throw a check in there to see if we have sufficient
>>material to mate (because at some point during the search it showed RxP KxR as
>>winning). I did, which eliminated that particular line...
>>
>>3. Maybe my hash table is screwing it up... turned that off. BINGO ... Wait..
>>no..
>>
>>Ok, so with the hash table on I get the drawing line immediately
>>
>>1. Ra2+ Kd1 Ra1 Kd2 Ra2 Kd1 etc but with a score of +3 pawns.
>>If I make the moves manually and then check my score, it is zero due to draw by
>>repetition.
>>
>>With the hash table off, I get a series of lines, albeit much slower:
>>
>>2 -355 157 Rc8 e1Q Rc7 Kd3
>>2 0 434 Re8 e1Q Rxe1 Kxe1
>>2 314 2182 Ra2 Kd1 Ra1 Kd2 <-- this is the drawing line
>>4 -355 7305 Rc8 e1Q Rc7 Qh4 Kc5
>>4 -345 12008 Rd8 e1Q Kc4 Kc2 Rd7
>>4 0 15734 Re8 e1Q Rxe1 Kxe1
>>4 314 68783 Ra2 Kd1 Ra1 Kd2 Ra2 Kd1 Ra1 Kd2 <-- here it is again
>>6 -365 445654 Rc8 e1Q Rc7 Qh4 Kc5 Qg5 Kd6 Kd3
>>6 -355 804284 Rd8 e1Q Rd7 Qh4 Kd5 Kc3 Ke6
>>6 0 956026 Re8 e1Q Rxe1 Kxe1
>>8 -375 29705128 Rc8 e1Q Rc7 Qh4 Kc5 Ke3 Kc6 Kd4 Rd7 Ke5 Kc5 <-- Start of a new
>>search, which means the drawing line never became the PV, which means everything
>>is working.. right?
>>
>>Ok, so I was thinking about how to solve this problem and the only idea I could
>>come up with was to modify the zobrist key after making the move if the position
>>was repeated.. i.e.,
>>
>>MakeMove (M) {
>>.../* Other stuff here */
>>...repeat_count = checkRepeats();
>>...if ( repeat_count > 0 ) key ^= zobrist_repeat[repeat_count - 1];
>>
>>}
>>
>>And I think this would solve the problem... but, oops, there goes my way to
>>check for repeats! If I modify the key then it will never be equal to the
>>repeated key so the repeat count will always be zero so I will never modify the
>>key so I will... etc
>>
>>So a couple of questions:
>>
>>1. Is my problem outlined above truely the hash table at fault
>>2. Do I *really* have to modify the key to get a good score back from a repeated
>>position? Does this mean I will have to keep two stacks of keys-- one for the
>>undo array and one just for checking repeats (the keys would be inserted before
>>modificiation)
>
>I don't understand how your engine was displaying random scores/pv with hash
>table off. That is the main problem, also check for draws before you check the
>hash. You shouldn't have to do #2 at all if you check for draws some other way.
>
>Michael
This is just a problem that can _not_ be solved without completely wrecking the
hash table. Draws depend on path information that is not a part of the hash
signature. You can retrieve a normal score from the hash that is wrong because
before you reach the endpoint that score came from, you pass through a draw by
repetition or 50 move rule that you won't know about.
It is just something you have to suffer through and ignore. It _will_ cause you
to draw a won game now and then...
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.