Author: Vasik Rajlich
Date: 15:48:12 09/01/04
Go up one level in this thread
On September 01, 2004 at 13:27:03, Tord Romstad wrote: >On September 01, 2004 at 06:01:02, Vasik Rajlich wrote: > >>On September 01, 2004 at 05:28:55, Tord Romstad wrote: >> >>>On September 01, 2004 at 05:00:32, Chris Welty wrote: >>> >>>>What is a Botvinnik-Markoff extension? >>> >>>An extension which is triggered every time the null move fails for the same >>>reason twice in a row. Whenever the null move fails low (you may want to >>>do it only when it fails low by some margin), you set ThreatMove[Ply] to >>>the move that refuted the null move. The code for the actual extension >>>is something similar to this (should be located directly after the null >>>move search in your code): >>> >>> if((null move failed low) && >>> (ThreatMove[Ply]==ThreatMove[Ply-2] || >>> (ThreatMove[Ply] and ThreatMove[Ply-2] captures the same piece))) >>> Extend >>> >>>The idea is to discover horizon effect problems more quickly. WAC141 is >>>a great example of how the extension works. After 1. Qxf4 Bxf4 2. Rxh5, >>>the null move is refuted by 3. Rh8#. After the continuation 3... gxh5 >>>4. Rxh5, the null move is again refuted by 4. Rh8#. Because the threat >>>move was the same at both nodes, the Botvinnik-Markoff extension is >>>triggered. >>> >>>I add the BM extension on top of all other extensions. This is the only >>>case where I occasinally extend more than a full ply. In the position >>>after 1. Qxf4 Bxf4 2. Rxh5 gxh5 3. Rxh5, the mate threat extension and >>>the BM extension is triggered simultaneously, and I extend by 3/4+1/2 >>>plies. >>> >>>>Is there a limit to the amount of mate threat extensions and BM extensions that >>>>you do? >>> >>>No. Many programs try to limit the extensions by dividing them by two >>>when Ply >= 2*IterationNumber, or something similar. I have tried schemes >>>like this many times, but it never had any positive effect for me. The only >>>limit I use is that I almost never extend by more than 1 ply at a single >>>node (the only exception is when the BM extension kicks in in addition to >>>some other extension, as explained above). >>> >>>Tord >> >>Tord, >> >>do you have any statistics for how often this extension triggers? > >I no longer remember exactly. The most precise information I can give >you is that it happens quite rarely. To some extent, you can control >how often it triggers by only doing a BM extension when the null move fails >low by some big margin (I use a margin of 2 pawns). > >>I'd guess that it's more of a positional extension than a tactical extension. >>Highly tactical positions should generally have varying refutations of a null >>move, while in a quieter position null moves could generally be refuted by the >>same quiet move. (Let's say something general like Nc3-d5.) > >My experience is the opposite. I once tried to print all positions where >the extension was triggered to a log file, and in the clear majority of >the cases, the threat was purely tactical (usually a mate or a hanging >piece). This is probably because of the 2 pawn margin mentioned above. >With the margin reduced to 0, I am sure many positional threats would >be extended as well. > >The way I use it, the extension's main purpose is to prevent horizon >effect problems. As an example, consider the following position: > >[D]8/B1p5/1pn5/5k2/8/7P/5PP1/6K1 w - - > >Assume that this position occurs close to the leaves, and that our program >is stupid, and does not realize by static eval that the bishop on a7 is >lost. White first tries a null move, but this is refuted by Nxa7. White >then tries 1. g4+, and black replies by 1... Kf4. In this position, white >tries a null move again. But once again, the null move is refuted by Nxa7. >Because the refutation move is the same as two plies earlier, the extension >is triggered. This increases the probability that the program searches >deeply enough to see that the bishop is lost. > >>Also - is this the same as Botvinnik's original formulation? I thought that null >>move was obscure back then. > >I haven't read any of Botvinnik's papers, but I guess his formulation must >have been different. Perhaps he used some other mechanism to detect >threats. The formulation of the extension described in this thread was >invented by Sergei Markoff. IIRC, Sergei originally called his version >the "pseudo-Botvinnik extension", but I didn't like this name and coined >the term "Botvinnik-Markoff extension" instead. > >Tord Thanks for the description. Yes, the 2-pawn window gives it a different purpose. One thing to note is that a null move will be refuted by >2 pawns more often when the remaining depth is low than when it is high (it's the nature of fail-soft), so you'll be doing this extension near the leaves more than near the root. This looks like another reason to think of this extension as a weapon against horizon effects. Vas
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.