Author: Andrew Platt
Date: 06:45:08 09/09/04
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.
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.