bizarre repetition detection issue

[Harald]

I have not identified a specific position, this is a systemic issue across _all_ trees where null-move is playable...

Yes, but I ask for examples, board pictures and list of moves, nothing specific, but, if possible, from real search of your engine.

I ask for it because I'm too stupid to be able to imagine why repetition draw detection across null moves could make sense in the first place, let aside this 4-plies-away-from-last-null-move rule (if I have understand it correctly).

A null move is a non-reversible move, right?
I can't undo a null move by moving a piece or by making another null move. But if both sides make a null move, they may annul each other in a way that makes it meaningful to check repetion draws across null moves.

Let's call any move before a null move an A-move.
Then one player does a null move.
Let's call any move after that a B-move.
Then the other player does a null move.
Let's call any move after that a C-move.

If there is no B-move or all B-moves are reversible we could search
for repetition backwards through C and A moves.
With more null moves we just have to skip every second X-moves.
The book keeping for this is easy and straight forward.
We just need a stack or two stacks, one for each player.
The stack can for each ply contain some flags, a link to a previous ply
that must be searched or a final stop sign.

Does this make sense?
Would it help?
Can someone test it?

Harald

[Ralph Stoesser]

I have not identified a specific position, this is a systemic issue across _all_ trees where null-move is playable...

Yes, but I ask for examples, board pictures and list of moves, nothing specific, but, if possible, from real search of your engine.

I ask for it because I'm too stupid to be able to imagine why repetition draw detection across null moves could make sense in the first place, let aside this 4-plies-away-from-last-null-move rule (if I have understand it correctly).

A null move is a non-reversible move, right?
I can't undo a null move by moving a piece or by making another null move. But if both sides make a null move, they may annul each other in a way that makes it meaningful to check repetion draws across null moves.

Let's call any move before a null move an A-move.
Then one player does a null move.
Let's call any move after that a B-move.
Then the other player does a null move.
Let's call any move after that a C-move.

If there is no B-move or all B-moves are reversible we could search
for repetition backwards through C and A moves.
With more null moves we just have to skip every second X-moves.
The book keeping for this is easy and straight forward.
We just need a stack or two stacks, one for each player.
The stack can for each ply contain some flags, a link to a previous ply
that must be searched or a final stop sign.

Does this make sense?
Would it help?
Can someone test it?

Harald

I think it makes sense.

Of course also a single null move can get annihilated by the opponent, by delaying a move himself (losing a tempo).

1. e2-e4 Nf6 (Alekhine's Defense)

or

1. e2-e3 <null> 2. e3-e4 Nf6 (Alekhine's Defense null move delayed)

Minimum length repetition without null move looks like this (4 plies):
<move a> <move b> <undo move a> <undo move b>

Minimum length repetition span a null move looks like this (6 plies each case):
<move a delayed> <null> <move a completed> <move b> <undo move a> <undo move b>
<move a> <move b delayed> <null> <move b completed> <undo move a> <undo move b>
<move a> <move b> <undo move a delayed> <null> <undo move a completed> <undo move b>
<move a> <move b> <undo move a> <undo move b delayed> <null> <undo move b completed>

[bob]

I have not identified a specific position, this is a systemic issue across _all_ trees where null-move is playable...

Yes, but I ask for examples, board pictures and list of moves, nothing specific, but, if possible, from real search of your engine.

I ask for it because I'm too stupid to be able to imagine why repetition draw detection across null moves could make sense in the first place, let aside this 4-plies-away-from-last-null-move rule (if I have understand it correctly).

A null move is a non-reversible move, right?
I can't undo a null move by moving a piece or by making another null move. But if both sides make a null move, they may annul each other in a way that makes it meaningful to check repetion draws across null moves.

Let's call any move before a null move an A-move.
Then one player does a null move.
Let's call any move after that a B-move.
Then the other player does a null move.
Let's call any move after that a C-move.

If there is no B-move or all B-moves are reversible we could search
for repetition backwards through C and A moves.
With more null moves we just have to skip every second X-moves.
The book keeping for this is easy and straight forward.
We just need a stack or two stacks, one for each player.
The stack can for each ply contain some flags, a link to a previous ply
that must be searched or a final stop sign.

Does this make sense?
Would it help?
Can someone test it?

Harald

Making it work is not the problem. My question was:

Why, after a null-move, does disabling repetition checks for the next 3 plies only provide the best results? If I don't go back beyond the null-move at all, that is clearly worse in testing. If I do go back beyond the null-move, but don't disable repetition checks until the fourth move after the null, that is clearly worse also. The best option, based on a ton of testing, is to test for repetitions normally, but not for the first 3 plies after any null is played.

I am still getting ready to run some very specific tests, and will report the results here...

[hgm]

Too bad you are unwilling to post a few sample repeat loops... That really makes it impossible for us to provide useful feedback

Except of corse for the case n=1 and n=2, which I already explained.

[bob]

Too bad you are unwilling to post a few sample repeat loops... That really makes it impossible for us to provide useful feedback

Except of corse for the case n=1 and n=2, which I already explained.

It is not that I am "unwilling". I simply have not looked at a single move to see what is going on. This came up in the middle of testing, where it was easy to change the rep detection rule(s) and then run a test.

We are talking 3-4-5-6 Elo here unless you go too far with the changes. So this is not exactly something that affects every position. In fact, these changes don't make much difference at all to something like win at chess. Might slightly change total nodes, but not number correct, etc...

[Ralph Stoesser]

Too bad you are unwilling to post a few sample repeat loops... That really makes it impossible for us to provide useful feedback

Except of corse for the case n=1 and n=2, which I already explained.

It is not that I am "unwilling". I simply have not looked at a single move to see what is going on. This came up in the middle of testing, where it was easy to change the rep detection rule(s) and then run a test.

We are talking 3-4-5-6 Elo here unless you go too far with the changes. So this is not exactly something that affects every position. In fact, these changes don't make much difference at all to something like win at chess. Might slightly change total nodes, but not number correct, etc...

Show us how your puppets play

Meanwhile I ask the Stockfish oracle whether it's good to check for rep draws over null moves. BTW you also could cross check with SF on your cluster, to be sure it's not a Crafty specific issue...

[bob]

Too bad you are unwilling to post a few sample repeat loops... That really makes it impossible for us to provide useful feedback

Except of corse for the case n=1 and n=2, which I already explained.

It is not that I am "unwilling". I simply have not looked at a single move to see what is going on. This came up in the middle of testing, where it was easy to change the rep detection rule(s) and then run a test.

We are talking 3-4-5-6 Elo here unless you go too far with the changes. So this is not exactly something that affects every position. In fact, these changes don't make much difference at all to something like win at chess. Might slightly change total nodes, but not number correct, etc...

Show us how your puppets play

Meanwhile I ask the Stockfish oracle whether it's good to check for rep draws over null moves. BTW you also could cross check with SF on your cluster, to be sure it's not a Crafty specific issue...

I will look to see what SF does. But I do not believe this is "crafty-centric". Question of the day is "what do most do about repetitions with respect to null-move." I believe most just do the normal test, based on the discussion about this very topic a few months back here...

[bob]

Too bad you are unwilling to post a few sample repeat loops... That really makes it impossible for us to provide useful feedback

Except of corse for the case n=1 and n=2, which I already explained.

It is not that I am "unwilling". I simply have not looked at a single move to see what is going on. This came up in the middle of testing, where it was easy to change the rep detection rule(s) and then run a test.

We are talking 3-4-5-6 Elo here unless you go too far with the changes. So this is not exactly something that affects every position. In fact, these changes don't make much difference at all to something like win at chess. Might slightly change total nodes, but not number correct, etc...

Show us how your puppets play

Meanwhile I ask the Stockfish oracle whether it's good to check for rep draws over null moves. BTW you also could cross check with SF on your cluster, to be sure it's not a Crafty specific issue...

I will look to see what SF does. But I do not believe this is "crafty-centric". Question of the day is "what do most do about repetitions with respect to null-move." I believe most just do the normal test, based on the discussion about this very topic a few months back here...

The short answer is that SF does not look back beyond the null-move when doing repetition detection.

I just finished a calibration run for 23.4, and am now re-adding in the 50-move counter limit for 23.5. I am going to run this test and then report the results. This simply uses the 50-move counter as a limit on how far back one can hunt for a repetition, and since Crafty resets the 50 move counter (SF does not, but has a separate counter for moves since a null was played) after a null, the two programs will be doing exactly the same thing. I have tested this more than once and found an Elo drop-off. This time I will report the results here once the test finishes this afternoon some time...

I am not sure why they maintain two counters, a 50-move counter and a moves-since-null counter. If repetitions previous to a null are ignored, I am not sure one would want to deal with 50 move draws since nulls are not going to make much sense there either...

[Ralph Stoesser]

The short answer is that SF does not look back beyond the null-move when doing repetition detection.

I have changed SF to look back beyond null-move. I've also tried the additional 4 plies from null limit (don't test for rep draw if plies-from-null < 4).

Both variants have played slightly weaker than default SF, but the results were well within the error margin (-4 Elo and -2 Elo). I've played only 2000 games each version.

I just finished a calibration run for 23.4, and am now re-adding in the 50-move counter limit for 23.5. I am going to run this test and then report the results. This simply uses the 50-move counter as a limit on how far back one can hunt for a repetition, and since Crafty resets the 50 move counter (SF does not, but has a separate counter for moves since a null was played) after a null, the two programs will be doing exactly the same thing. I have tested this more than once and found an Elo drop-off. This time I will report the results here once the test finishes this afternoon some time...

Probably not much Elo to gain here. But interesting anyway.

I am not sure why they maintain two counters, a 50-move counter and a moves-since-null counter. If repetitions previous to a null are ignored, I am not sure one would want to deal with 50 move draws since nulls are not going to make much sense there either...

As would seem natural they use the 50-move counter for 50 move rule tests.
And they use the plies-from-null counter for counting the plies from last null move.
I'd say it's easy to understand.

[bob]

The short answer is that SF does not look back beyond the null-move when doing repetition detection.

I have changed SF to look back beyond null-move. I've also tried the additional 4 plies from null limit (don't test for rep draw if plies-from-null < 4).

Both variants have played slightly weaker than default SF, but the results were well within the error margin (-4 Elo and -2 Elo). I've played only 2000 games each version.

I just finished a calibration run for 23.4, and am now re-adding in the 50-move counter limit for 23.5. I am going to run this test and then report the results. This simply uses the 50-move counter as a limit on how far back one can hunt for a repetition, and since Crafty resets the 50 move counter (SF does not, but has a separate counter for moves since a null was played) after a null, the two programs will be doing exactly the same thing. I have tested this more than once and found an Elo drop-off. This time I will report the results here once the test finishes this afternoon some time...

Probably not much Elo to gain here. But interesting anyway.

I am not sure why they maintain two counters, a 50-move counter and a moves-since-null counter. If repetitions previous to a null are ignored, I am not sure one would want to deal with 50 move draws since nulls are not going to make much sense there either...

As would seem natural they use the 50-move counter for 50 move rule tests.
And they use the plies-from-null counter for counting the plies from last null move.
I'd say it's easy to understand.

Also, IIRC, the stockfish starting point is ply - 4 so it is already excluding the first 4 plies, whether by design or by accident is unknown. Normally you would start looking 4 plies back since you can't repeat any sooner, but null-move changes that and you can repeat sooner than that...

Perhaps we both found the "optimal value" quite by accident... Still testing however...