TalkChess.com

I´m working in add the 3rd repetition rule recognition by my engine.
I did a pair of tests I could imagine and seems to work, but I´m still not happy, I need more tests to feel sure it works.

There are some place where to find positions to test if your engine recognizes the 3rd repetition rule?

Wich is the usual way to test this?

Thanks!

This is the only two examples I found to test it.
First I fixed the search depth in 2 and the evaluation in just 100 for pawns; 300 for bishops and knights; 500 for rooks and 900 for queens.
So is easy to see all that the engine could think that is too little.

In both cases the engine uses whites and me blacks.

In the right board the king first do not want to leave the c1/c2 squares cause if it do it, it lost a pawn and his advantage decreases from 200 to 100, but after few moves must left those squares no matter to lost the pawn cause if not, the 3rd repetition rule give 0 points to it that is worst than the 100 it still have with one pawn less.

In the left board the idea is the same, if blacks just move its king, after some moves it needs to sacrifice the g3 pawn, or the rook, to not tie being ahead in points.

Are two unrealistics positions, but I could not imagine any other, specially thinking in test the en passant pawn and different castle conditions as not detected as tie!

Luis Babboni wrote:I´m working in add the 3rd repetition rule recognition by my engine.
I did a pair of tests I could imagine and seems to work, but I´m still not happy, I need more tests to feel sure it works.

There are some place where to find positions to test if your engine recognizes the 3rd repetition rule?

Wich is the usual way to test this?

Thanks!

What I generally do is give my program two rooks on the 7th hemming in the opponent's king. give the opponent a Q+R so that a repetition is preferable. Then make sure you didn't leave any holes where the two rooks mate on the spot, or you can't repeat because the opponent's queen or rook covers one of the key checking squares. A couple of extra pawns for the opponent and your program can close off the mating opportunities and make the back and forth on the 7th rank perpetual the best choice...

This?:

What about special cases like not tie cause one of the repetitions in fact is with different castle conditions or cause one pawn was able to be captured in apssant or the turn to move is not the same?

I found a lot of "testsuites", but could not find nothing about test 3rd repetition rule.
I did not a good search?

A position I used.

[D]qq3rk1/ppp1p2p/3p2p1/8/8/3Q4/2Q3PK/8 w - - 0 1

But draws by repetition have a very high occurrence during gameplay so lots of opportunity to see it in action.

Bugs tend to come from getting the en passant and castling rights wrong.

In my previous engine Neurosis I had a bug that it would set en passant rights when a pawn moved up 2 squares even when no pawn was there to capture it. This bug was exploited right at my first OTB computerchess tournament where it drew a better position by surprise.

Another way I've catched bugs in my hash keys is through noticing severely interrupted PV's as I pull the PV from the hashtable. A problem case for me was updating castling rights after captured rooks. I do not test every capture for castable rooks but look for missing rooks on next ply during movegeneration and update castling rights there.

Luis Babboni wrote:This?:

That's one of many possibilities

Luis Babboni wrote:What about special cases like not tie cause one of the repetitions in fact is with different castle conditions or cause one pawn was able to be captured in apssant or the turn to move is not the same?

That's a different problem. If your hash signature is correct, this kind of test will test your repetition detection. If you hashing screws up with en passant, side to move or castling rights, then nothing is going to work right and 3-fold repetition will be the least of your worries.

I do not test every capture for castable rooks but look for missing rooks on next ply during movegeneration and update castling rights there.

Do you consider castling rights in evaluation followed by stand-pat in Qsearch?