Bug in threefold repetition detection with en passant

Sort:
Toldsted

I agree!

Martin_Stahl
danielbaechli wrote:

The threefold repetition detection seems wrong when en passant is involved.

In the following example, the threefold repetition is said to occur after 6... Bc8 and the game is automatically drawn. However, the threefold repetition looks at the position, the possibility to capture en passant and castling status, so the threefold repetition occurs only after 8.. Bc8, not before. chess.com should automatically draw the game (if that is necessary at all, as in OTB there is no automatic draw with threefold repetition, but that is another question) after 8.. Bc8, not after 6... Bc8.

Example:

1. e4 Nf6
2. e5 d5 {Position arises, e5 can capture d5 en passant, repetition count #1}
3. Be2 Bd7
4. Bf1 Bc8 {Position arises, e5 cannot capture d5 en passant, so repetition count back to #1}
5. Bd3 Be6
6. Bf1 Bc8 {Position arises, e5 cannot capture d5 en passant, repetition count #2}
7. Bc4 Bf5
8. Bf1 Bc8 {Position arises, e5 cannot capture d5 en passant, repetition count #3}

 

Do you have a game where this happened? As far as I'm aware, the triple repetition code correctly accounts for that, though it is always possible a bug crept in.

Martin_Stahl

Nevermind, I see that you had a game like that. Did you do that in Play (Beta)?

jdcannon

Checking it out. Play (Beta) vs /live doesn't really matter here. They both use the same server which determines draws here. 

jdcannon

We will fix, but turns out this has been the case for like a 15 years and no one noticed till now.  Probably won't be in that big of a hurry to fix. 

Martin_Stahl
jdcannon wrote:

We will fix, but turns out this has been the case for like a 15 years and no one noticed till now.  Probably won't be in that big of a hurry to fix. 

 

It is something that is rarely seen, even OTB.  I assume the fix is to check more of the FEN string, if so, castling rights also need to need checked if they aren't currently.

Martin_Stahl
danielbaechli wrote:

Is there any update on this? Now you have a complaint. I will do some trash talk here, don't take this literally, but to the point. <trash talk>Either you are bloody beginners, then you should not fix that, for then everybody can see that you are bloody beginners, and as you are it is not a problem. Otherwise, if you aren't bloody beginners (which is the right assumption), you really should fix this quickly, for else somebody might incorrectly assume that you are.</trash talk> Oops, I just wrote that for I think to kick in the "well but it doesn't happen a lot" excuse is very bad!

 

The last post by @jdcannon is the update. He said since the code has been that way for 15 years it probably won't be done quickly 

DjVortex

By strict FIDE rules, the theorical maximum number of visual board repetitions (ie. all pieces are on the same squares) without the 3-fold repetition rule kicking in is 22. This is because for a position to be considered truly repeating, all of these requirements must be met:

  1. All squares contain the same types of pieces (two of the same piece swapping squares among themselves doesn't matter).
  2. It must be the same player to play.
  3. All the possible moves must be the same. This includes castling rights and en passant right. (Note that a piece being hard-pinned, or castling being impossible because the king would end in check or pass through a checked square doesn't affect this. It's still considered a "possible move" in this regard.)

Almost no chess software gets this 100% right (and if you try to artificially repeat the same visual position 22 times using the rules above to avoid 3-fold repetition, chances are that whatever software you are using will declare it as 3-fold repetition before that.) Likewise basically no chess engine bothers to check the 3-fold repetition rule to this extent.

Martin_Stahl

Only staff can answer that question, but with any minor bug and edge case one, it is very likely low priority. I wouldn't count on it being fixed soon.

Lagomorph
danielbaechli wrote:
 

I wanted to ask again about an update regarding the topic.

Give it a rest mate. they acknowledge there is a problem. They have told you it is low priority and wont be fixed soon.

Too much crap going on in this world right now to get your knickers in a twist over this. pour yourself a glass of wine and watch the sunset.

Martin_Stahl

I would be very surprised out of the millions of games played per day if any of them had this particular issue, disregarding ones where the plan was to see if the code handled it correctly.

Martin_Stahl

The reason to mention the probable rarity, is that rarity plays into how urgent the bug is to fix. If it hasn't really impacted that many members and it's been around for as long as it has, it would be a very low priority bug fix.

msnwork121
Hello dear friends, I have a problem. No matter how much I play, whether I win or lose, my score does not change. Please, if anyone has experience in this matter, please guide me. Thankful
Lagomorph
danielbaechli wrote:

Thanks for the feedback. Let's repeat this a few more times: I say it should be fixed soon for it belongs to the basic rules, you say that it can take its time for it occurs rarely. Both statements are correct: It belongs to the basic rules and occurs rarely, just we have different opinions on how to weight this. That is fine. The example is just for illustration, it shows that this can occur for games of highest rated players. Of course, very rarely, still, but it is possible.

Not this again !  You ever heard the expression "wasp in your ear" ?

Martin_Stahl
rachellakitten wrote:

And if it's as easy as you say it is to fix, then fixing it won't take a lot of work. So just fix it and worry about less important stuff later.

 

Don't think anyone said it was easy, only that it is a relatively minor bug; i.e. one that survived since live was implemented without coming to the attention of the devs.

 

Since it touches live server code, it would take very thorough testing as well.

Lagomorph
rachellakitten wrote:

And this bug will probably take a lot less work to fix then updating all this stuff that works just fine and doesn't need to be updated.

Then submit your re-written code for chess.com to consider. They may even pay you for it.

rasma912

I run into a lot of chess bots that seem to be perfect in their games. I forgot which bot I played but they got a perfect score on me, every time I would attack they would move out of my attack perfectly to take my pieces. I am pretty sure that it is impossible to play a perfect game. To lose no pieces and take all of yours makes no sense to me. I PLAY BETTER THAN THAT!

SOSOonagain

The code to chess.com is open source?! Anyway. When a pawn is moved two squares one could check if opponent has any pawns able to capture en passant. Then if true three fold repetition can't occur for this position and first repetition should not be set. Don't see a lot of tests being needed to confirm that would work. Assuming my thinking on the solution is correct/viable in the first place. I don't know how they do it in their current code.

Martin_Stahl
Ripley_Osbourne wrote:
Martin_Stahl a écrit :

The reason to mention the probable rarity, is that rarity plays into how urgent the bug is to fix. If it hasn't really impacted that many members and it's been around for as long as it has, it would be a very low priority bug fix.

If FIDE was pointing out rarity for a reason not to fix a rule, it would be a scandal. Therefore, I don't believe rarity is a valid reason when it comes to Chess rules, or you're invalidating the seriousness of you ratings and competitions, when you already did not bother make some agreement with the FIDE, which is questionable by itself. My opinion.

 

But a business pointing out a rarity that has no real world ramifications, that is normal. And FIDE has changed the draw rules a number of times based on mating possibilities and move counts based on tablebase findings. Then changed them back, partially due to the rarity of the endings and the ability to successfully execute. Now we're back to 50 move claims and 75 move forced draws. It's not like something like that is unprecedented.

Martin_Stahl
SOSOonagain wrote:

The code to chess.com is open source?! Anyway. When a pawn is moved two squares one could check if opponent has any pawns able to capture en passant. Then if true three fold repetition can't occur for this position and first repetition should not be set. Don't see a lot of tests being needed to confirm that would work. Assuming my thinking on the solution is correct/viable in the first place. I don't know how they do it in their current code.

 

My guess is that there isn't a counter but a FEN string is associated with each position and the check for triple repetition isn't looking at the whole string and doesn't look at the the en passant flag in the check