Author: Tord Romstad
Date: 10:27:03 09/01/04
Go up one level in this thread
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
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.