Author: Vincent Diepeveen
Date: 20:05:58 09/29/00
Go up one level in this thread
On September 28, 2000 at 15:59:25, Peter McKenzie wrote:
>On September 28, 2000 at 13:53:40, Ernst A. Heinz wrote:
>
>>Hi Vincent,
>>
>>>I lack the time and especially motivation to create articles,
>>>also i don't get paid to write them.
>>
>>Me neither and I assume the same applies to Bob. Academic
>>institutions do not pay you for your scientific publications.
>>They are rather a pre-requisite for the real jobs.
>>
>>>>If you already explained what it is, I missed it. I do not
>>>>know what you mean exactly by "double null move". How and
>>>>when do you apply it? What about experimental evaluation?
>>>
>>>the double nullmove enhancement is real simple explained by a few
>>>lines of code
>>>when to nullmove, assuming you store in an array movelist[128]
>>>the moves, and the current real depth is realdepth (the actual
>>>number of moves made).
>>>
>>>if( !incheck && !pawnendgame
for practical bugfixing perhaps let's add another thing realdepth <=2,
in case most people didn't see it, most commercial programs nowadays
also nullmove in the root, no kidding. when running nimzo and junior
you can easily see it, as they select a -- move first, though i don't
nullmove in the root in DIEP it sure is worth some more thoughts
and tests!:
>>> && (
realdepth <= 2
|| movelist[realdepth-1] != nullmove
>>> || movelist[realdepth-2] != nullmove)( { // then allow nullmove
>>> movelist[realdepth++] = nullmove;
>>> ..
>>>}
>>
>>Hmh, is "movelist" indexed by full moves (i.e, stores the
>>moves for one side only) or ist it indexed by plies?
>I believe it is indexed by plies
yes,
if we start in opening position
move realdepth side to move
e4 0 white
e5 1 black
nf3 2 white
null 3 black
nc3 4 white
null 5 black
null 6 white
?? 7 black
Now at the questionmarks
at realdepth == 7 we are NOT allowed to nullmove, a third
consecutive nullmove in a row is not allowed. so in diep
i *always* nullmove but i don't allow the 3d nullmove in a row
to happen. I do allow a total of n nullmoves all together though.
So now at readlepth==7 black is FORCED to make a move
in the same position as where black started to nullmove,
so it's logical that you search in a correct way, as you
have a reduced depth, but in a position x you always need to
make a move, perhaps not initially but later on you sure are
forced to make a move with a side x.
>>In the latter case, "movelist[realdepth-1] != nullmove"
>>is a natural condition that almost everybody enforces
>>("DarkThought" included).
this condition is using more nodes for me as the
above condition.
A bit less nodes compared to my double nullmove is simply always
allowing a nullmove for DIEP.
So compared to always allowing a nullmove (no conditions at all),
this double nullmove sure takes an overhead as it eats nodes, but
only after a huge reduction factor.
>
>
>Right, so Vincent's condition is less strict. Perhaps I can explain this a
>little clearer, although the ideas are from Vincent and not me.
>Most programs allow a nullmove if the previous move wasn't a nullmove.
>'Double-null' allows a nullmove if EITHER of the previous 2 moves weren't null.
>In other words, it allows 2 nullmoves in direct succession, but not more than 2.
>
>Surprisingly(?), this turns out to be a very elegant way to detect zugzwang. I
>say elegant because there is no special zugzwang detection code necessary, it is
>just picked up as a property of the search. It will be take some extra plies to
>find a zug as opposed to a normal non-nullmove search, which is probably why
>Vincent still turns nullmove off in pure pawn endgames.
>
>A disadvantage is that you are effectively doing extra work in middlegames,
>where zug is very rare but then again the amount of extra work must be very
>minimal - perhaps a small cost to pay for peace of mind and having a
>'theoretically correct search' ?
i go for the theoretical correct search!
>By 'theoretically correct search', Vince means a search that is capable of
>solving ANY problem given enough time (unlike a normal nullmove search which of
>course can never solve many zugzwang problems).
>I've never tried using double nullmove so haven't done any serious testing of
>it, but I'm quite impressed by the simplicity of the idea. I know that Don
>Daily was using a form of it in CilkChess (based on a conversation we had about
>it in Paderborn). I think Don allows at most 2 nullmoves in any branch of the
>search tree, and he allows those 2 nullmoves to be in direct succession.
>
>Enjoying your book by the way.
>
>Looking forward to the double nullmove section in the 2nd edition :-)
Exactly i could not have said it better!
>cheers,
>Peter
>
>>
>>=Ernst=
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.