Author: Vincent Diepeveen
Date: 02:58:56 07/18/02
Go up one level in this thread
On July 17, 2002 at 13:18:40, Christophe Theron wrote: >On July 16, 2002 at 11:01:23, Vincent Diepeveen wrote: > >>On July 15, 2002 at 13:11:09, Christophe Theron wrote: >> >>>On July 15, 2002 at 08:37:34, Omid David wrote: >>> >>>>I don't think using double null-move is a good idea in practice, since in >>>>midgame the chance of zugzwang is negligible and thus it's superfluous (I doubt >>>>if even DIEP uses it). However the contribution of double null-move is that it >>>>gives legitimacy to the null-move pruning idea, proving that it _is_ a correct >>>>search method (anyway, no one doubts null-move nowadays). >>> >>> >>> >>>Why does double null move prove that null move is a correct search method???? >>> >>>Doing two null moves in a row means going back to standard search (a search not >>>involving an illegal move like null move is). >>> >>>I fail to see how it legitimates null move. >> >>Double nullmove legitimates (duh can't you use easier to spell words) >>itself, for the obvious reason that it is provable now that a search >>depth of n ply, where i may pick n, is going to solve any problem you >>give it. > > > >OK, I see now. > >However, it is not true. > >Due to a nasty interaction with the hash table algorithms, just allowing 2 null >moves in a row will NOT solve any problem. What you refer to is a practical impossibility (assuming you have a efficient search) : your assumption is that from a root position r with transition of some moves to position p, side stm to move and depthleft=d: r ==> p(stm,d) that you visit this position with properties that before this move you have made 1 nullmove or less. so ==> r , nullmove , p Now a major problem for such an event to occur is that after 1 nullmove, sides change the side to move. However i don't know how you do this in tiger, but what we are interested in is the mainline. We aren't interested in a bunch of stupid moves which can go to this position x. In fact we already don't reach it by stupid moves because in DIEP i directly try the nullmove, before searching other moves. So we would already have had a cutoff before getting to p with stm to move and >= d. Secondly, i want to see zugzwang in mainline, i don't care for sidelines. So from a mainline r , firstmove , nullmove , p(stm,d) Somehow you claim that you managed to get in p without already getting a cutoff by nullmove? That's impossible, because you would already have had a cutoff! Now the second position where we *do* find a zugzwang: r , firstmove , nullmove , nullmove , p(stm,d) Your assumption is now that somehow we get with transposition of hashtable a cutoff. That means you already searched p *somehow* with >= d for stm, before in the tree. that means that you did get a fail low after: r , firstmove , nullmove score < beta, otherwise a transposition is not possible to position p(stm,d). Now let's take a look at *which* position we got the < beta score: r , firstmove , p(stm,d+R+2) nullmove If we already get a score < beta *somehow* in position p(stm,> d) that means obviously we already caught the zugzwang, so we still find the zugzwang then by means of transposition after r , firstmove , transposition , p(stm,<= d) Best regards, Vincent >It is necessary, in order to solve any problem, to add some logic in the HT >algorithms, or to disable the HT completely. > > > > Christophe > > > > >>Normal nullmove, if you remember the discussions a few years ago, >>especially around 98 and 99, it was told to be an inferior way of >>search, because for *any* selfpicked depth n for the nullmove search >>it could conclude less than a small outdated fullwidth search, so was >>the theory. >> >>This is not true of course. >> >>Reality is that only a few problems need a bit bigger search depth >>with double nullmove, and most are far endgames. >> >>In middlegame it's very seldom one needs 3 ply more than a fullwidth >>search would get. >> >>Note that getting a fullwidth search of more than 12 ply is impossible >>whereas most get 14-15 ply with nullmove nowadays easily in tournament >>practice. >> >>DIEP's probably only exception here, it needs a supercomputer to get >>that depth ;) >> >> >> >> >>> >>> >>> Christophe
This page took 0.03 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.