Ah, my misunderstanding then. I've never really dug into the FEN specification and thought it only was listed if an en passant capture was possible against that pawn.
Bug in threefold repetition detection with en passant
Sort:
I agree this is an issue that must be fixed as a priority. With this basic rule issue not fixed, we are playing the wrong chess on this site.
Nov 10, 2020
0
#24
The bug is in the Live server code, has apparently existed since it's inception and hadn't been reported until recently. Apparently, if anyone has had it happen in a real game before, they haven't reported it.
Code changes have priorities based on severity and the risks associated with modifying the code. The site has apparently decided that this problem is apparently very low priority, based on the rarity of it happening. While I have no other insight, other than the staff input on it, so can't say how low that priority is, but I'm going to guess it's fairly low on the list. It not being fixed has very little impact on the vast majority of the games being played as well, so it's very possible that it will be a while before it's fixed, assuming it hasn't been. My guess is that if/when there is a major rewrite of the back-end live code, that will be part of that work.
Nov 11, 2020
0
#25
Live server code is the code that runs all the Live games. It is a separate process and one that is integral to playing chess, other than Daily. Basically, mission critical code for the site.
As I said, I have very little insight beyond that and what has been stated by a staff member. There are other projects relating to Live that are apparently of much more importance to the site, than fixing this particular issue, one that impacts a very minor number of games. My guess is that most days, not even one actual game is incorrectly drawn due to the omission, over millions of Live games.
Nov 15, 2020
0
#26
danielbaechli wrote:
...
To assume that it does not happen a lot, even when not sure, is discomforting to me. As long it is not clear, I would expect an assumption in the other direction, to be on the safe side.
I'm certainly not a decision maker here. Just stating my thoughts, and indeed, my guesses, some influenced by what I've read from staff 
Just from experience, in playing and in being a TD in OTB events, triple repetitions occur mostly in the endgames and I know I've seen only a couple of topics where people thought they had a triple repetition of position, where the first position had en passant available.
And you're right, it is hard to spot a lot of time in regular games. The site used to require players to make the claim, so in the past, there were a lot of potentially drawn games that got missed because players didn't see it or weren't able to claim in the time scrambles.
Now that it it is automated, which is different that OTB anyway, it would be fairly easy (from the site's perspective) to see how many games end that way and extrapolate how likely the topic situation arises. The site has apparently decided it is lower priority, and as I've said, I would be very surprised if it happens with any frequency at all.
danielbaechli wrote:
I am surprised that there was a practical assessment of how much it can happen but no further reaction.
I want to mention that I came across another bug. I described this bug here: https://www.chess.com/forum/view/general/bug-related-to-insufficient-material-rule-no-impact-on-serious-games-though
The bug with repetition is rare but can happen in real games. The bug above regarding insufficient material is very unlikely to my opinion.
Both are bugs, so to be mentioned. I deem it normal behaviour to report bugs and also a completely normal expectation that they are fixed at some point. Contrary I find the reaction on the first mentioned problem rather outside the norm of today's software development standards.
Whenever a program is changed to fix a problem there is a risk of a different problem being unintentionally introduced. ANY change would require extensive checking to make sure both that the change fixed what it was supposed to fix AND that the change did not introduce another problem. EVERY function would need to be tested. Most companies that spent millions of dollar purchasing software packages to run their businesses understand that any fix of any bug has a risk of other bugs being unintentionally introduced, and thus even the smallest fix takes time. If a problem does not appear that often then the software companies assign it a low priority even when it significantly affects one or two of the many, many companies using the software.
I understand that attitude regardless of how irritating I find it to be.
danielbaechli wrote:
I deem it normal behaviour to report bugs and also a completely normal expectation that they are fixed at some point.
They will be fixed at some point. You have been told that. If it does not happen as quickly as you like then go and start your own website. You really are becoming the forum bore.
Nov 25, 2020
0
#29
danielbaechli wrote:
I am surprised that there was a practical assessment of how much it can happen but no further reaction.
I want to mention that I came across another bug. I described this bug here: https://www.chess.com/forum/view/general/bug-related-to-insufficient-material-rule-no-impact-on-serious-games-though
The bug with repetition is rare but can happen in real games. The bug above regarding insufficient material is very unlikely to my opinion.
Both are bugs, so to be mentioned. I deem it normal behaviour to report bugs and also a completely normal expectation that they are fixed at some point. Contrary I find the reaction on the first mentioned problem rather outside the norm of today's software development standards.
The most important thing for the site is trying to keep Live stable and running with the vast increases in memberships and traffic since March. A minor bug, while likely on the problem list, is likely so far down that list it will be a long time until it is even looked it.
Mar 2, 2021
0
#30
Martin_Stahl wrote:
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.
https://support.chess.com/article/1042-i-got-a-draw-by-repetition-how-did-that-happen
According to our rules, and forgive me if someone else on the thread has addressed this, as well as FIDE and USCF rules, is that a position is not the same if the right to castle and en passant are different.
mtmoves wrote:
According to our rules, and forgive me if someone else on the thread has addressed this, as well as FIDE and USCF rules, is that a position is not the same if the right to castle and en passant are different.
Everyone is aware of what you say which is correct.
Martin has addressed the issue and made clear it will be fixed, but you will have to be patient.
May 18, 2021
0
#32
@Lagomorph "[...] You really are becoming the forum bore." With all the necessary respect, I find this statement demonstrates a lack of basic respect. You are free to have your own different opinion about the subject. But it is in no way acceptable to personally discredit other people having a different opinion, in this case, myself. I have invested a considerable amount of time presenting the subject.
While your opinion is free, it is part of basic respect to respect other people's effort, in my understanding. I can't see this respect in your posts. Also, I do not see any relevant contribution to the subject on your side. Discrediting other users is not a contribution. Taking the side of chess.com, like putting up the scenario the platform may become unstable, is not your responsibility.
To return the favour, for the reasons stated above, I find your statements inasmuch unuseful, as you deem mine.
danielbaechli wrote:
@Lagomorph "[...] You really are becoming the forum bore." With all the necessary respect, I find this statement demonstrates a lack of basic respect. You are free to have your own different opinion about the subject. But it is in no way acceptable to personally discredit other people having a different opinion, in this case, myself. I have invested a considerable amount of time presenting the subject.
To be clear to you, I was not intending to treat you with respect. You have pointed out an issue which chess.com staff have acknowledged is an error in coding. They have also told you why it will not be fixed quickly.
If you were to understand their reasons why this will not be fixed quickly, you would not continue to post every few months another complaint on the same issue ( you now seem to have deleted all of them).
chess.com programmers have a duty to all of the users of this site, not just you. Once you understand that I will accord you the respect you deserve.
Uživatel DjVortex napsal:
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:
- All squares contain the same types of pieces (two of the same piece swapping squares among themselves doesn't matter).
- It must be the same player to play.
- 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.
Well, the only thing you need to check if the FEN strings are the same (aside from pieces, you have 4 castling flags, 1 ep square, and a player to move). No quick chess engine saves the positions in FEN during calculations, but if it would, all it needs to check if any path in the game tree contains the same string 3x.
However, there is actually one case - and in that all EP positions, the possibility to capture has to be checked explicitly. See this answer:
https://chess.stackexchange.com/a/33515/24210
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
The FEN supplies the information that a pawn has moved two squares. and which square it passed. But not if en Passent is possible. So there is no flag for that.
You do have a check for en passant though, since you provide the possibility at the appropriate time. The first thing that happens in that check is probably to look for an en passant square. If it is there you look for opposing pawns able to capture en passant.
If there isn't any, one solution would be to change the en passant square to '-', i.e. no en passant possible, before adding it to whatever functionallity you have to determine number of repetitions. Then that functioality could include looking at that position in the string too. In terms of what else that FEN could be used for I don't believe this would change anything. Anyway, I was just puzzled at the hesitance to approach the problem. I may be difficult for any number of reasons I am not aware of. But from a pure problem solving point of view it doesn't seem so complicated.