My engines consider the null-move as an irreversible move, and hence do not look for repetitions that span a null move. The reason is that I don't want the side that is losing to be able to refute a second null move by retracting its previous move and claiming draw:
null - cr*p move - null - reverse cr*p move!
forcing the side that deserves the fail high to do an expensive real search in stead of the second null move.
It seems wrong, however, to search on beyond the repetition. (And in fact, it wrecks my SMP scheme, setting me thinking about this problem.) If the score would propagate to the root, you would effectively have replaced the score of high-depth search with that of a lower-depth search. This usually invites horizon effects. If there is a good continuation for either side, that side could have played it immediately, from the first occurrence.
The idea of the null move is that the current position is "good enough", and the opponent cannot harm you even when you don't do anything. Creating a repeat is not really making progress towards harming you. If he could do something after the repeat to hurt you, he should have done it immediately, and have a deeper search on it. If it does not hurt you then, the latter result is to be believed, not the artificially-reduced search.
I am not completely sure what to return, however, in stead of searching on. Perhaps the current evaluation? That would put the burdon to avoid the repeat on the side that is not happy with the current evaluation in the node of the first occurrence of that position, which is probably not the side that is null moving. That seems satisfactory in repeat loops where only one side null-moves. My doubt stems mainly from that it is not clear to me if this would also work for longer loops where both sides throw in one or more null moves. (It might, but I cannot conceive a simple argument that it will...)
Null-move repeats
Moderator: Ras
-
- Posts: 28387
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 65
- Joined: Thu Jul 08, 2010 9:16 am
Re: Null-move repeats
Hi,
first I try to recapitulate the nullmove.
White to move. White skips move (nullmove) and search is done with black to move. If now value is >= beta a nullmove cuttoff will be done.
If we allow (I currently don´t know what Spike is doing here ...) black to return zero because auf repetetive draws the amount of nullmove cuttoffs will be reduced if beta >= 0.
I agree, that repetetive draws should not be returned as a nullmove search result (only if a position is reached twice in the nullmove search itself).
To your question: What to do if black is reaching a repetive position:
Option 1: Return Zero -> Not a good idea because of less nullmove cuttoffs.
Option 2: Return Alpha -> This will solve the problem of Option 1, but is not good either. This might result in a nullmove cuttoff even if the repetetive position is good enough for black. Engines do nullmoves even if eval is < beta. If white can´t do anything better than keeping the old posiotion with value < beta it is ok to not do a nullmove pruning.
Option 3: Return evaluation -> Does not make any sence to me. Evaluation without search is too near to a random result.
Option 4: Do a "normal" search. This is in IMHO the only good option. The additional search done is not relvant. I think we will see many hash hits here.
Greetings Volker
first I try to recapitulate the nullmove.
White to move. White skips move (nullmove) and search is done with black to move. If now value is >= beta a nullmove cuttoff will be done.
If we allow (I currently don´t know what Spike is doing here ...) black to return zero because auf repetetive draws the amount of nullmove cuttoffs will be reduced if beta >= 0.
I agree, that repetetive draws should not be returned as a nullmove search result (only if a position is reached twice in the nullmove search itself).
To your question: What to do if black is reaching a repetive position:
Option 1: Return Zero -> Not a good idea because of less nullmove cuttoffs.
Option 2: Return Alpha -> This will solve the problem of Option 1, but is not good either. This might result in a nullmove cuttoff even if the repetetive position is good enough for black. Engines do nullmoves even if eval is < beta. If white can´t do anything better than keeping the old posiotion with value < beta it is ok to not do a nullmove pruning.
Option 3: Return evaluation -> Does not make any sence to me. Evaluation without search is too near to a random result.
Option 4: Do a "normal" search. This is in IMHO the only good option. The additional search done is not relvant. I think we will see many hash hits here.
Greetings Volker
Mangar Spike Chess
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Null-move repeats
We had this discussion here a few months back, probably in a different (non-SMP) context. I did some testing and found that the best scheme is to pay no attention to null-move. And let repetitions occur across a null-move just like they occur across any other reversible move.hgm wrote:My engines consider the null-move as an irreversible move, and hence do not look for repetitions that span a null move. The reason is that I don't want the side that is losing to be able to refute a second null move by retracting its previous move and claiming draw:
null - cr*p move - null - reverse cr*p move!
forcing the side that deserves the fail high to do an expensive real search in stead of the second null move.
It seems wrong, however, to search on beyond the repetition. (And in fact, it wrecks my SMP scheme, setting me thinking about this problem.) If the score would propagate to the root, you would effectively have replaced the score of high-depth search with that of a lower-depth search. This usually invites horizon effects. If there is a good continuation for either side, that side could have played it immediately, from the first occurrence.
The idea of the null move is that the current position is "good enough", and the opponent cannot harm you even when you don't do anything. Creating a repeat is not really making progress towards harming you. If he could do something after the repeat to hurt you, he should have done it immediately, and have a deeper search on it. If it does not hurt you then, the latter result is to be believed, not the artificially-reduced search.
I am not completely sure what to return, however, in stead of searching on. Perhaps the current evaluation? That would put the burdon to avoid the repeat on the side that is not happy with the current evaluation in the node of the first occurrence of that position, which is probably not the side that is null moving. That seems satisfactory in repeat loops where only one side null-moves. My doubt stems mainly from that it is not clear to me if this would also work for longer loops where both sides throw in one or more null moves. (It might, but I cannot conceive a simple argument that it will...)
You can always "hash" the null-move to stop this, but it was definitely worse when I did so... As a result, I allow repetitions to occur across the null-move. There are "real" ways to play a null-move anyway, such as you want to play Bc1-e3, but you play Bc1-d2 and Bd2-e3. Effectively you "passed" on one of those turns to play, yet you allow repetitions to occur. I suppose one can argue that if you are well ahead, and "pass" for one move, and your opponent can repeat, then you are not as far ahead as you thought.
In any case, "fixing this" cost Elo when I tested it. Not huge Elo, but something in the 8-10 range IIRC.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Null-move repeats
I disagree. I actually tested this when the same topic came up a few months ago. Breaking repetition across a null-move is trivial, you just hash in something like "null-random[ply]" (has to be different random number for each ply or two nulls in the same path will "undo" the hash change.) Doing this is a -8 to -10 Elo change. I actually ran several 30K game test matches and found it best to allow repetitions across a null. I will re-check, to be sure, however, and post the results here.Mangar wrote:Hi,
first I try to recapitulate the nullmove.
White to move. White skips move (nullmove) and search is done with black to move. If now value is >= beta a nullmove cuttoff will be done.
If we allow (I currently don´t know what Spike is doing here ...) black to return zero because auf repetetive draws the amount of nullmove cuttoffs will be reduced if beta >= 0.
I agree, that repetetive draws should not be returned as a nullmove search result (only if a position is reached twice in the nullmove search itself).
To your question: What to do if black is reaching a repetive position:
Option 1: Return Zero -> Not a good idea because of less nullmove cuttoffs.
Option 2: Return Alpha -> This will solve the problem of Option 1, but is not good either. This might result in a nullmove cuttoff even if the repetetive position is good enough for black. Engines do nullmoves even if eval is < beta. If white can´t do anything better than keeping the old posiotion with value < beta it is ok to not do a nullmove pruning.
Option 3: Return evaluation -> Does not make any sence to me. Evaluation without search is too near to a random result.
Option 4: Do a "normal" search. This is in IMHO the only good option. The additional search done is not relvant. I think we will see many hash hits here.
Greetings Volker