Author: Christophe Theron
Date: 07:50:39 01/27/01
Go up one level in this thread
On January 26, 2001 at 22:49:31, Vincent Diepeveen wrote:
>On January 26, 2001 at 12:11:51, Christophe Theron wrote:
>
>>On January 25, 2001 at 19:06:58, Robert Hyatt wrote:
>>
>>>On January 25, 2001 at 12:21:34, Gian-Carlo Pascutto wrote:
>>>
>>>>On January 25, 2001 at 11:00:46, Robert Hyatt wrote:
>>>>
>>>>>Anytime you reduce the depth, I would call that a "negative" extension...
>>>>
>>>>My point was that nullmove doesn't really reduce the depth:
>>>>it does a _different_ (with nullmove included) search with
>>>>a reduced depth, and decides based on that whether to cut
>>>>or not.
>>>>
>>>>I do not consider the nullmove search to be part of the
>>>>normal search, it is just a fancy way of establishing a
>>>>bound and pruning based on what that bound is. Nullmove
>>>>prunes, it doesn't reduce the depth (of your _real_ search).
>>>>
>>>>If you, for example, would reduce the depth of your main
>>>>search by a ply if your nullmove failed high, I'd consider
>>>>that to be a negative extension.
>>>>
>>>>The main reason why I make this distinction is that any
>>>>effect by a negative extension should be circumventable
>>>>by searching deeper. This is not true for nullmove, because
>>>>it cuts (based on a dynamic criterion which happens to
>>>>include searching something _else_ with reduced depth).
>>>>
>>>>Vincent's double nullmove(*) _could_ be considered a negative
>>>>extension, because it will pick up zugzwang's eventually
>>>>if depth is increased. This is not true for normal nullmove.
>>>>
>>>>(*) If it works like I remember...I think that you do
>>>>two consecutive nullmoves and hence end up in the normal
>>>>search again?
>>>>
>>>>--
>>>>GCP
>>>
>>>The point of a double-null is that if it is my move, and I pass, the search
>>>might actually fail high because not moving wins. If I follow this null
>>>move search by one for you, yours will also fail high if it is a true zugzwang
>>>position, and if you return beta, my null-move search will fail low and I keep
>>>searching normally..
>>
>>
>>
>>Sounds like the gigantic depth reduction resulting from a double null move will
>>push the detection of these zugzwang cases very far away.
>>
>>The total depth reduction after two consecutive null moves is 3+3=6 (if you use
>>R=2).
>>
>>So you will avoid to fall into zugzwang traps, but you will need 6 plies more
>>than a brute force search. It's still better than never seeing them (which is
>>the case with regular null move), but does not sound better than a much simpler
>>system: when you suspect that a zugzwang COULD happen in the position or later
>>in the search, enable null move only in the last plies near the horizon.
>>
>>For example enable null move only in the 6 plies before the horizon when you
>>reach post-middlegame positions, or endgame positions. You'll get the same
>>result than the double null move system, but you will simply need less nodes.
>>And the code will also be simpler.
>>
>>
>>
>> Christophe
>
>To find tricks at problem testsets you are very right that turning
>off nullmove is a smart thing to do if you suspect some problems to happen.
>
>The big question is *how* do you detect problems?
>
>If we all agree on that in pawn endgames and
>being in check is a condition we can't nullmove
>anyway then my whole experience in positions was
>that:
> - nullmove is a superb way of searching
> - i can search huge number of plies extra
> by using nullmove in positions with 1 piece or
> more.
> - sometimes a position has a zugzwang
> - i would like to search in a way which i can't get
> a big surprise. The positions that happen once in
> a hundred years or made by some weirdo called 'endgamecomposer'
> i don't care much for. So in short at depth = n where i
> may chose n i want to see a zugzwang happening.
> - the few endgames where i had a zugzwang in the zugzwangs
> were all requiring real low search depths. Also examples
> i could find in GM games were all not worth it.
>
>So in short i don't want to burn too many nodes to find a zugzwang,
>and more important: i want to have something that finds *anything*
>at depth=n where i may chose n, so i can say that according to my
>definition of a correct search (which is already mentionned implicitly)
>double nullmove is a correct way of searching.
>
>Now back to the testsets.
>
>At bs2830 of course the Short-Timman game is of course a big
>headache for whoever uses nullmove. Searching fullwidth there you
>find Kg3 faster as without nullmove.
>
>Kind of 'pestering' nullmove programs position.
>
>Nevertheless you can without doubts keep nullmove within your program.
>
>Same is true for Bxe4 position in lctii testset. There double nullmove
>will have huge problems with Bxe4 as the whole trick is a very deep
>trick. Losing a lot to double nullmove is of course very expensive there.
>
>But with a simple trick you can already fool the people who made the
>testset of course!
>
>Is it worth it however?
>
>From all those positions your prog gets on the board, is it worth
>to waste nodes on not nullmoving in a position which in 99.999% of
>the positions is completely nonsense to search and which importance
>for the root is even less significant as giving away a piece is usual
>VERY losing and there is a BIG chance you still see yourself winning
>if you can give a piece away for just 1 passer which is stopped.
>
>Well perhaps one day i solve the Bxe4 problem in the Rebel way,
>but for sure in similar positions i prefer diep to nullmove and
>double nullmove.
>
>I find the relevant positions easily IMHO. I can't show you a single
>game where i lost the point because of searching with nullmove
>instead of turning it off.
>
>I can show you however a lot of games where i DID lose points because i
>had forgotten to turn on nullmove.
>
>In dutch open i showed someone the difference between searching with
>nullmove and without nullmove.
>
>That's just 1 parameter in DIEP. 1 command to the engine to turn nullmove
>off and it searches without.
>
>As a result of that i searched without nullmove in the games
>
>The King - DIEP
>
>and
>
>DIEP - Patzer
>
>Diep allowed something HORRIBLE against patzer because of NOT using
>nullmove, as even search would have fixed this bug in my king safety
>evaluation (which of course also is fixed).
>
>Against The King there everyone can analyse the big mistakes both
>progs made, because both hardly used nullmove that game seemingly...
>...especially that endgame with very little pieces, and slowly
>the pieces got off the board...
>
>Now suppose you are in such a difficult endgame with each 2
>pieces and you do with
>a condition "if 1 piece then do not nullmove", so every stupid
>line IMHO where 1 piece gets from the board, there you stop
>nullmoving.
>
>So nearly everyone can easily figure out that all your nodes go to
>positions where you can't nullmove!
>
>This is why i'm very happy with double nullmove. The huge reduction
>needed to detect a zugzwang is clearly a weakness when you try to solve
>testpositions where you need actually a fullwidth search to
>solve the position quicker (so doing less nullmoves somewhere in the
>lines will definitely speedup your solve time), but i don't dare to
>think of that alternative hurting nearly every tough endgame my program
>plays!
I understand your point. However I must add that the double null move algorithm
has a cost. In middlegame positions for example, it should increase the number
of nodes (compared to standard null move).
Have you measured the tree growth generated by double nullmoving?
Have you tried to do a strength comparison between simple and double nullmove?
Christophe
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.