repetition draw bug

[hgm]

Checkmate, stalemate and insufficient material terminate the game immediately by rule whereas one has to claim a draw by fifty move rule or repetition else the game will continue. So insufficient material should have a higher priority than fifty move rule and repetition.

That was my first thought too. Until I realized that when there is both a 50-move and an insufficient material draw, the material must have already been insufficient for 50 moves...

[stevemulligan]

The priority ranking is:

1) Checkmate
2) Stalemate
3) Fifty move rule
4) Repetition rule
5) Insufficient material rule

My results still don't match up after accounting for the priority and matching your insufficient material function as best I could.

Code: Select all

rgstat 10000
 Checkmate: 2815 (0.2815)
 FiftyMoves: 1048 (0.1048)
 Insufficient: 5858 (0.5858)
 Repetition: 96 (0.0096)
 Stalemate: 183 (0.0183)
Elapsed Time 82.636s (121.0126)

I'm assuming checkmate/stalemate code is working because my perft scores are matching in a large test suite I have.

For 50 move rule, I manage the half move clock like this (reset on pawn move or capture)

Code: Select all

if ((pieceKind[mdest] == PieceType.Pawn) || (CapturedPieceType != PieceType.All) || (LastMoveType == MoveTypeAI.Promotion))
                DrawCount = 0;
            else
                DrawCount++;

For repetition I use zobrist hashes in a dictionary so I know if a position has occurred 3 times in the game.

The only place I think I might have made an error is insufficient material, yet that # is the closet match

Code: Select all

public bool NewSufficientMaterial()
{
   return (NewSufficientMaterialByColor(PlayerColor.White) || NewSufficientMaterialByColor(PlayerColor.Black));
}

public bool NewSufficientMaterialByColor(PlayerColor color)
{
    if ((GetBB(color, PieceType.Pawn) > 0) || (GetBB(color, PieceType.Queen) > 0) || (GetBB(color, PieceType.Rook) > 0))
                return true;

    List<ulong> k, b;

    k = Util.SplitBB&#40;GetBB&#40;color, PieceType.Knight&#41;);
    b = Util.SplitBB&#40;GetBB&#40;color, PieceType.Bishop&#41;);
            
    if (&#40;b.Count >= 2&#41; || &#40;k.Count >= 3&#41;)
                return true;

    if (&#40;b.Count > 0&#41; && &#40;k.Count > 0&#41;)
                return true;

    return false;
&#125;

[sje]

My results still don't match up after accounting for the priority and matching your insufficient material function as best I could.

Code: Select all

rgstat 10000
 Checkmate: 2815 (0.2815)
 FiftyMoves: 1048 (0.1048)
 Insufficient: 5858 (0.5858)
 Repetition: 96 (0.0096)
 Stalemate: 183 (0.0183)
Elapsed Time 82.636s (121.0126)

The checkmate count is nearly double the 15.2% expected. I have FEN files of 100,000 checkmates and 100,000 stalemates and I can send them to you if you think they might be helpful.

[stevemulligan]

The checkmate count is nearly double the 15.2% expected. I have FEN files of 100,000 checkmates and 100,000 stalemates and I can send them to you if you think they might be helpful.

Thx for sending them. All the checkmates & stalemates match up for me.

I'm going to try saving the fen of all the so-called checkmates from random games and verify them using this same method.

[stevemulligan]

The checkmate count is nearly double the 15.2% expected.

Could differences in the prng be an issue? I can't find any problems in my draw conditions, perft & mate tests all pass.

[sje]

The checkmate count is nearly double the 15.2% expected.

Could differences in the prng be an issue?

Only if your PRNG is seriously broken. My guess is that there's a bug with the repetition code.

[stevemulligan]

Ok, making progress. How close do I have to be to your #'s with a million samples to be confident I have gotten rid of any repetition/draw bugs?

Code: Select all

rgstat 1000000
Summary:
  Checkmate 153,174 (0.153174)
  FiftyMoves 193,469 (0.193469)
  Insufficient 567,328 (0.567328)
  Repetition 25,273 (0.025273)
  Stalemate 60,756 (0.060756)
Count: 1,000,000   Elapsed: 3485.771  (286.88 Hz / 0.003485771 s)

It's my first time reading LISP so I'm not sure on these two points:

• 1. I'm matching your insufficient material criteria as best I can. To get similar results this criteria needs to match exactly right?
  
  2. In the CIL.lisp file you sent me it looks like the priority is 50 move, insufficient, repetition based on defun pos->pdgt. Am I reading that right? Asking because you said in this thread you checked repetition before material. (That's how I'm doing it, and I get closer to the #'s you posted when I do that - I just wanted to check if I was reading the LISP code correctly)

[sje]

Ok, making progress. How close do I have to be to your #'s with a million samples to be confident I have gotten rid of any repetition/draw bugs?

It's my first time reading LISP so I'm not sure on these two points:

• 1. I'm matching your insufficient material criteria as best I can. To get similar results this criteria needs to match exactly right?
  
  2. In the CIL.lisp file you sent me it looks like the priority is 50 move, insufficient, repetition based on defun pos->pdgt. Am I reading that right? Asking because you said in this thread you checked repetition before material. (That's how I'm doing it, and I get closer to the #'s you posted when I do that - I just wanted to check if I was reading the LISP code correctly)

I'd try for at least a million games to give at least three significant digits of agreement.

Assuming that the program can reliably detect game termination, the priority order won't matter much, maybe less than one in several thousand games.

I think you've got the insufficient material code working okay.

Maybe someone needs to publish a repetition detection test suite. This would be a collection of PGN data with games with know game termination including repetition draws.

[sje]

Here is the game termination assignment code from Bozochess:

Code: Select all

function poscalcgt(var pos: postype): gttype;
var
  result: gttype;
begin
  with pos do
    begin
      if posisnomoves(pos) then
        if inch then result := gtcheckmate else result := gtstalemate
      else
        if posisfiftymovesdraw(pos) then
          result := gtfiftymoves
        else
          if posisinsufficientdraw(pos) then
            result := gtinsufficient
          else
            if posisrepetitiondraw(pos) then
              result := gtrepetition
            else
              result := gtunterminated;
      poscalcgt := result;
    end;
end; { poscalcgt }

[stevemulligan]

Maybe someone needs to publish a repetition detection test suite. This would be a collection of PGN data with games with know game termination including repetition draws.

Are there any compiled linux apps that I will play a random game and save to PGN format? I could run that and collect a big library of repetitions/50 move pgn's. If left to my own devices I'm gonna fire up Perl again :p