Author: Robert Hyatt
Date: 08:25:15 10/02/03
Go up one level in this thread
On October 02, 2003 at 05:35:16, Tord Romstad wrote: >On October 01, 2003 at 19:02:43, Robert Hyatt wrote: > >>On October 01, 2003 at 14:01:52, Tord Romstad wrote: >> >>>On October 01, 2003 at 13:50:49, Robert Hyatt wrote: >>>> >>>>It seems to me that Chrilly's paper on null-move search included this >>>>idea as the "threat extension". >>> >>>It is not the same. The "deep search extension" (the term Chrilly used, >>>IIRC) extends in all positions where the null move fails low by a >>>sufficiently high margin, as you explain. The Botvinnik-Markoff >>>extension is different. It extends when the null move fails low at >>>ply n _for the same reason_ as the null move failed low at ply n-2. >>> >>>I have never seen this idea before. It seems original and interesting. >>> >>>Tord >> >>OK. It is just a restricted "singular extension". If a move is singular >>at two consecutive plies for the same side, it gets extended. > >Huh? I don't understand what you are saying here, I'm afraid. Unless >I am missing something, the extension seems totally unrelated to singular >extensions. Where are the singular moves? The "singular move" is the move that is refuting the null-move. It isn't exactly the same thing, obviously, but it fits here pretty well. > >>The "for the >>same reason" seems wrong, since all you are looking at is the refutation move. >>Note that the _best_ move is not needed to produce a cutoff, just "a good enough >>move". That means it is more than just barely likely that two different moves >>will cutoff and cause the null-move search to fail low at two consecutive >>plies for the same side. This could happen when history totals change, killer >>arrays/counts change, one gets a hash hit the other doesn't, etc... > >This problem can be reduced (though of course not completely eliminated) >by a minor modification to the move ordering. In my implementation, I >search moves with the same target as the refutation move from two plies >earlier directly after the move from the hash table (this move ordering >trick is only done at nodes where the move leading to the node was a null >move, of course). > >So far, it seems to work rather well, at least in my program. > >Tord
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.