Author: Andrew Platt
Date: 08:12:04 09/09/04
Go up one level in this thread
On September 09, 2004 at 10:02:59, Michael Henderson wrote: >On September 09, 2004 at 09:45:08, Andrew Platt wrote: > >>I have a problem where my search can use values from previous iterations I would >>rather they didn't use! Normally the depth field would protect against this >>because the depth of the earlier iteration would be lower than the next >>iteration and we wouldn't use the entry. However, with null moves because the >>depth is lowered, this can confuse things. This shows up from the following >>position: >> >>4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - - >> >>You may recognize this as WAC 141 (again!). The key move is Qxf4! which I spot >>at iterate ply 9, though I don't see the mate there because the search drops >>into the quiescent search where I don't see the final move Rh8# (I don't >>generate / deal with checks in qsearch). >> >>So we back up non-mate scores which, as expected, end up in the hash table - >>including the following: >> >>Qxf4 Be5 Rxh5 Bxf4 (ply 4, depth 270) >> >>In iteration 10 the search reaches this point pretty quickly: >> >>Qxf4 Bxf4 Rxh5 NULL_MOVE (ply 4, depth 210) >> >>Since with the null move this becomes white to move, that makes the position >>identical to the one above stored in the hash table. The depth in the table is >>greater than the current depth so we use the value. If the value isn't in the >>table (which of course happens sometimes if I play around with the hashtable >>size, etc.) it will try Rh8# as the null move, return a mate score and generate >>an extension that will allow it to find the mate in this ply. >> >>I know that other programs, such as Crafty, store the mate threat in the >>hashtable. However, I can't see that would help here since that would get >>overwritten by the update anyway. >> >>Any suggestions? >> >>Andy. > >When you store a beta cutoff with null move in the hash table do you store the >regular depth and not depth - R? I don't know if you are doing this but you >might be... Also do you do a hash cutoff even if you are in check? I store the current search depth not the reduced search depth. So, if we're within the scope of the null search it will store positions with the reduced depth appropriate; but when returning the beta cutoff we store it at the normal search depth, just as we will store it at the ply above with that depth if appropriate. Is this wrong? I don't do a null move search when in check. Andy.
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.