Author: Michael Henderson
Date: 08:45:16 09/09/04
Go up one level in this thread
On September 09, 2004 at 11:12:04, Andrew Platt wrote: >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. You are doing it correctly. But if you get a hash cutoff for a node does it account for possible extensions at the node? I recently put in some extensions and I think you have to take care of this.
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.