Author: Vincent Diepeveen
Date: 03:37:52 10/16/02
Go up one level in this thread
On October 16, 2002 at 05:56:07, Thorsten Czub wrote: >On October 16, 2002 at 05:00:53, Gian-Carlo Pascutto wrote: > >>On October 16, 2002 at 03:47:01, Vladimir Medvedev wrote: >> >>>In his online interview Mr. CrazyBird told that DB did not use nullmoving >>>because it is not compatible with singular extensions. Could somebody explain >>>what are "singular" extensions (which difference with general meaning of >>>extensions technique? Are singular extensions used only for one move in the >>>node, while "common" - for all moves from the node? ) >> >>Singular extensions means extending a move if it is the only 'good' >>one in a position, for example if it is better than all other by >>half a pawn. >> >>>Why are they incompatible with nullmoving? >> >>I have no idea what CB was thinking about. I use them, and >>I use nullmove, and it works fine. >> >>-- > > >don't you think that much resources got wasted by SEX ? For deep blue biggest waste were 3 things IMHO : - parallel inefficiency (99% of all system time) - searching fullwidth (bigger branching factor 6.0 overall) - inefficient hardware processors (90%) Of course those numbers If the only inefficiency would have been searching fullwidth, then that's still possible to overcome. But very inefficient search within the hardware processors which waste for sure around 90% of their total number of nodes to things the software isn't doing (when searching fullwidth). Of course we must not forget they were the first to get that deep. Also some, like Hyatt were claiming bigtime around 1997-2000 that nullmove was very dubious to use. However, with exception of for example Kh2 in Short-Timman, i see very little positions in middlegame and start of endgame where nullmove is needing extra plies compared to fullwidth search. And usually those extra plies you get anyway :) Double nullmove (2 nullmoves in a row finding the zugzwang; not turned on when in check or when in pawnendgame) removes the zugzwang problem. With exception of a handful of idiotic semi-closed positions, double nullmove is finding all the zugzwangs. Nullmove works especially well with good implemented hashtables. It is not so effective in hardware without hashtables like it is in software with hashtables. Good example is last 3 ply of a position. You replace by qsearch. So 3 iterations in a row you use the same single qsearch score for the SAME line. Not to mention loads of transpositions. Now you can call that dubious, or you can be happy to get 2 ply extra... The huge search depths of today are basically caused by that combination of nullmove with effective hashtable usage. That wasn't trivial in 1997 yet. Not to mention the early 90s when the deep blue project started. >>GCP
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.