Author: Robert Hyatt
Date: 16:27:17 09/02/02
Go up one level in this thread
On September 02, 2002 at 13:42:18, Omid David wrote: >On September 02, 2002 at 13:34:16, Robert Hyatt wrote: > >>On September 01, 2002 at 17:08:58, Omid David wrote: >> >>>On September 01, 2002 at 12:08:21, Uri Blass wrote: >>> >>>>On September 01, 2002 at 11:55:32, Vincent Diepeveen wrote: >>>> >>>>>On September 01, 2002 at 10:20:08, Uri Blass wrote: >>>>> >>>>>if you search for aske plaat you will find his stuff on >>>>>mtd online probably. i'm amazed that you don't understand >>>>>that Frans is using nullmove. >>>> >>>>I know that he is using null move but I do not use null move when I search the >>>>line that is in the previous pv because I consider it a waste of time. >>>> >>>>Null move is for prunning illogical lines. >>>> >>>>The pv cannot be illogical line so the only case when I can save nodes by null >>>>move pruning when I am in a pv line is when the position is zugzwang. >>>>In other words I can save nodes only if null move pruning is wrong. >>>> >>>>I understood that MTD says that the pv may be wrong but the first ply of the pv >>>>is always right so it does not make sense to prune after Nc6. >>>> >>>>Uri >>> >>>It depends on what you want; if you want "the first move, only the first move, >>>and nothing but the first move", then use MTD(f). But if you also want the PV >>>(as most of us do), avoid it. >>> >>>The use of null-move pruning follows the logic behind each method: In MTD(f), >>>you only want the first move, so you are free to use null-move pruning even in >>>the PV, something you shouldn't do in regular NegaScout/PVS. >> >>You are not thinking this thru clearly. null-move on the PV makes perfect >>sends. You are searching one ply different. It might suddenly change things >>in a significant way and null-move is the fastest way to dismiss a bad line, >>whether it was part of the PV from the previous iteration or part of some >>non-root move that is hopeless. >> >>You should try it in a program, doing it everywhere and only doing it on non- >>PV searches. I think you will be surprised. I was. The comments in main.c >>should explain when I made this change myself after someone (Bruce I think) >>suggested it and testing proved him correct. >> >> >> >>> >>>P.S. >>>Aske Plaat first introduced MTD(f) in his 1995 article "An Algorithm Faster than >>>NegaScout and SSS* in Practice" available at >>>http://www.cs.vu.nl/~aske/Papers/hk.pdf >>> >>>For a more intuitive explanation, look up http://www.cs.vu.nl/~aske/mtdf.html >>> >>>Plaat suggests that MTD(f) is faster than NegaScout, but he researched only >>>fixed-depth full-width trees. I haven't seen any publication concerning MTD(f)'s >>>behavior in variable depth trees (e.g. using null-move pruning). >> >> >>I suspect it is "break even" once you get it right. NO way to avoid at least >>two searches, and, in general, more than that. Which means that with a program >>with a complex evaluation, the researches are going to cause problems and make >>it catch up to PVS or even pass it. >> >>I think that for normal programs, they should be equivalent if they are both >>implemented with the same skill and development time. > >Actually I think MTD(f) needs more time for fine tuning. For example, you have >to adjust the evaluation function to a good degree, since the behavior of MTD(f) >can change to a great extent depending on the eval function; while PVS isn't >that dependant on the eval function. I wouldn't argue against that very much. Although the eval takes work to get right, even with pure alpha/beta. :)
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.