Two fold or three fold repetition?

[Sven]

Not much magic. This code returns true if it thinks it is a draw:
...
What can go wrong? Maybe zobristkey representation wrong value??

Are you really sure that you have not read the TT for the current position at that point?

[Henk]

Not much magic. This code returns true if it thinks it is a draw:
...
What can go wrong? Maybe zobristkey representation wrong value??

Are you really sure that you have not read the TT for the current position at that point?

Yes TT reading comes later or after this check.

But Aspiration searches calls PVS. Maybe I should disable apiration searches to be sure it has no effect.
But I think no influence.


trace: isadraw, tt, doMove, isadraw, tt, doMove etc

[amanjpro]

Why are you clearing position history upon pawn move or capture? You only need to reset the 50 moves counter for those, and that is it

[Henk]

It uses a dictionary. History is implemented as a dictionary. Does not know time. So you need to clear dictionary otherwise it contains to many positions.

[Henk]

Hmm. Strangely PVS without aspiration searches going wrong now. First have to fix that. Who knows its related to three fold rep bug.

[Sven]

Hmm. Strangely PVS without aspiration searches going wrong now. First have to fix that. Who knows its related to three fold rep bug.

I would not see any connection between aspiration and repetition ... And I would focus on only one issue at at time ...

[Sven]

In your last example game, after 61...Rg3+ this position "P1(1)" is reached:

[d]8/5k2/R3p3/PpN1P3/1P3P2/2K3r1/8/4n3 w - - 1 62

and is repeated twice, with 63...Rg3+ ("P1(2)") and 65...Rg3+ ("P1(3)").

After 62...Rg2+ the position "P2(1)" is reached:

[d]8/5k2/R3p3/PpN1P3/1P3P2/8/1K4r1/4n3 w - - 3 63

which is repeated once after 64...Rg2+ ("P2(2)"). In both instances of P2 the "bad" program version plays Kc3 and allows the opponent to repeat by playing Rg3+.

I would try to track down the issue by printing appropriate debug output showing what happens directly at P1(1), P1(2), P2(1) and P2(2) (relevant parts of search decision process at these nodes) for these cases:

1) Set up P1(1), search to depth 8 with TT enabled
2) same as 1) with TT disabled
3) Set up P1(1), play user moves 62.Kb2 Rg2+ 63.Kc3 Rg3+ 64.Kb2 Rg2+ without searching ("force" in WB protocol), search to depth >= 2 with TT enabled
4) same as 3) with TT disabled

Maybe you even find better testing scenarios. I would try to print output only when reaching exactly these positions. HGM has posted his method for that purpose a couple of times. You need to find out
a) why the engine decides to play Kc3 in the P2 positions (so print PV and score for up to six legal moves) and
b) what it does in the P1 positions (checked for repetition, result? TT read/store? any moves searched - PV and score?).

[Henk]

Looks like bug is gone. I don't understand why. There was a bug in PVS I fixed. Looks like it also fixed three fold bug.

Bug in PVS was that I eliminated first branch and forced a research for the first move. For you want it to use a full window.
But that trick does not work. Still don't know why. Sometimes it did not find a bestMove.

Might be 3fold repetition bug not gone but taking far more time to reproduce.

Riddle, riddle.

[Henk]

Code: Select all

  
         if (positionHistory != null)
            {
                var key = new ZobristKey(this, ZobristTable.Instance);
                positionHistory.Add(key.Rep);
            }
 

This code allocating memory and also has given up multi processing (ZobristTable.Instance?)

[Henk]

Code: Select all

  
         if (positionHistory != null)
            {
                var key = new ZobristKey(this, ZobristTable.Instance);
                positionHistory.Add(key.Rep);
            }
 

This code allocating memory and also has given up multi processing (ZobristTable.Instance?)

Also not hiding representation of key but efficiency rules. Better positionHistory.Add(key) I think.