In the position you’ve linked, it goes like this. White plays Bg2+. He calls it checkmate but of course it isn’t. Black plays d5#. This is checkmate. The fact that white can (or could, if it got him out of check) capture the pawn on d5 en passant doesn’t meant it never really got to d5; the rules are perfectly clear that a White capture en passant is a thing that happens (if it does) on White’s following move. The etymology of the term is neither here nor there. White cannot, in fact, now play cxd6 e.p. because that move doesn’t get him out of check. And despite White’s fanciful interpretation of how the game rules, an e.p. capture does not, in fact, have any sort of retroactive effect. Of course Black’s pawn got to d5; it is already there.
This is true, as long as white has no pawn intersecting power. Which today is a defacto standard. And “en passant” isn’t “en passant”, but “as if en passant, but only after the taken pawn has occupied some other field than the one his slayer occupies know”.
This should be make clear, or things are vague, ill-defined.
I think you are complaining that the official rules of chess merely define the rules of chess, and don’t also take care to offer explicit contradictions for every confused notion someone reading them impressionistically might arrive at.
There is nothing in those rules to imply or even suggest that either player has “pawn intersecting power”, if by that cryptic phrase (perhaps you mean “intercepting” but the meaning is still obscure) you mean some sort of retroactive interference with a previous move. It’s true that the rules also don’t explicitly deny that—in the same way as they don’t explicitly deny (say) that if you push the same pawn three times in a row then you get to remove one of your opponent’s pieces. They don’t need to, because neither is something a reasonable person would expect on reading the rules.
“En passant” is merely a technical term. It is not necessary for the rules to say explicitly “even though the term comes from the French for ‘in passing’, the pawn completes its move and is then removed only by the capture next move” because that is obvious from the actual rules as stated. Just as it is not necessary for them to say explicitly “even though the term ‘checkmate’ comes from words meaning ‘king dead’, checkmate is achieved as soon as the king is in check and has no way to escape; actually capturing the king is not required”. Or “even though the players are called white and black, it is not necessary for the actual players to be white and black respectively”. Or “even though the knight in some sense represents a man on a horse, a knight’s move can pass over intervening pieces representing things that would be too high for a real horse to jump over”.
There is nothing ill-defined here (at least, not so far as the example you’ve given tells us; there might be errors or omissions I haven’t noticed).
I would be happy to bet my $100 against your $10 that none of the 10 most widely used chess engines takes a different view of this situation from the one I describe. … Well, actually I wouldn’t, because the nuisance of agreeing details and testing chess engines and so on greatly outweighs the value to me of $10, but in principle I would.
I don’t really see that this would “decide who is right”, though; if people had been writing chess engines back when the rules failed to stipulate that castling has to be horizontal or that promotions have to be to pieces of your own colour, I bet they would mostly have implemented those features in the “expected” way. If there are subtle omissions in the present-day rules, they probably aren’t reflected in actual chess engine code.
The question is, how their rules of engagement looks like. Especially, what is the mechanism dealing with the en passant? Is it plain like in the FIDE’s rules?
I don’t think so.
They are different. You see, pure mathematics is like a program in Python written on a sheet of paper. You actually don’t know, if it would run or not.
The same goes for the game rules. Humans do out-negotiate from most situation if not all, but that doesn’t mean that the rules of the game (in this case chess) are without a problem.
I’m not sure I understand your question about “their rules of engagement”. But I took a look at one chess engine’s source. This is Robert Hyatt’s “Crafty”, which at one time was one of the leading engines (others have overtaken it now). Many things are represented as 64-bit bitmaps. Here, accordingly, is its special code for e.p. captures.
First, in a function called GenerateCaptures there is a line that says this:
target = Occupied(enemy) | EnPassantTarget(ply);
Everything from “|” inclusive to ”;” exclusive would be omitted if there were no e.p. captures. Second, there is some special-cased code for generating moves when in check (since of course you then only need to consider moves that might get you out of check). Here’s the relevant code:
Without e.p. captures this would be simplified in fairly obvious ways. Third, as well as generating moves there is some code for validating moves (I haven’t looked at how it’s used, but I guess it’s just for verifying that an opponent’s move is legal; I’m not sure why it isn’t good enough to generate all legal moves and see if the given move is among them, since it’s hard to see how efficiency would matter for this). Here’s the relevant bit:
and this thing needs initializing, setting when a pawn advances two squares, incorporating (since e.p. status is a sometimes-important feature of a position) into the hash function used when storing previously-examined positions, and various bits of bookkeeping (e.g., in the tree search it is convenient to “flip” the position, interchanging the roles of black and white, and the e.p. status is one of the things that needs swapping over). And that’s it.
None of this (of course) involves any sort of reverse-causation where an e.p. capture causes the captured pawn never to have reached the square it nominally moved to. And, aside from the fact of being formalized in computer code, it all seems to me pretty much exactly as clear-cut as in the FIDE rules.
I had a quick look at the source of Stockfish, one of today’s top engines. It seemed fairly similar in complexity, except that Stockfish seems to take some notice of e.p. status in its analysis, which means there’s e.p.-related code that isn’t strictly needed merely because the rules are what they are.
You don’t actually know, if it [sc. mathematics] would run or not.
I think you know as well as you do for many pieces of software that have been run. After all, pure mathematics is used all the time by pure mathematicians, and less directly by physicists, engineers, etc. There might be bugs, but so might there be in software that has been used for years.
[EDITED to fix some code-formatting errors and remark that the remaining ones are probably unfixable because AFAIK there’s no good way to stop spaces at the starts of lines being eaten.]
The first is this about chess. How the rules of chess are defined for chess engines, are they really just a copy of what the official FIDE rules are, and how this is going to play out for some crucial positions.
I argue, that the human rules are a bit vogue and that some engines are very likely well designed, but their rules are a bit different. At least more complete.
The second is about mathematics, how likely everything is consistent there. Very unlikely, if you ask me. But almost certainly very likely all is okay, if I ask you. Even if there are paradoxes, they are so very well hidden, that no surface scanning is going to find one. The ZF has been scrutinized quite deeply and all is okay. That’s your view if I understand you correctly.
The third is about math and software. You are saying, that a lot of mathematics is constantly used by a lot of programs and that program bugs are somewhat a problem, but that there is almost certainly no math bugs.
Here we disagree again. I think there might be some unseen math bugs, too. Probably not in finite simple mathematics, but maybe even there. But quite possibly when things get really complicated.
Perhaps I will not refer to another problem involving infinities here. Just to avoid some unnecessary disputes.
In the position you’ve linked, it goes like this. White plays Bg2+. He calls it checkmate but of course it isn’t. Black plays d5#. This is checkmate. The fact that white can (or could, if it got him out of check) capture the pawn on d5 en passant doesn’t meant it never really got to d5; the rules are perfectly clear that a White capture en passant is a thing that happens (if it does) on White’s following move. The etymology of the term is neither here nor there. White cannot, in fact, now play cxd6 e.p. because that move doesn’t get him out of check. And despite White’s fanciful interpretation of how the game rules, an e.p. capture does not, in fact, have any sort of retroactive effect. Of course Black’s pawn got to d5; it is already there.
This is true, as long as white has no pawn intersecting power. Which today is a defacto standard. And “en passant” isn’t “en passant”, but “as if en passant, but only after the taken pawn has occupied some other field than the one his slayer occupies know”.
This should be make clear, or things are vague, ill-defined.
I think you are complaining that the official rules of chess merely define the rules of chess, and don’t also take care to offer explicit contradictions for every confused notion someone reading them impressionistically might arrive at.
There is nothing in those rules to imply or even suggest that either player has “pawn intersecting power”, if by that cryptic phrase (perhaps you mean “intercepting” but the meaning is still obscure) you mean some sort of retroactive interference with a previous move. It’s true that the rules also don’t explicitly deny that—in the same way as they don’t explicitly deny (say) that if you push the same pawn three times in a row then you get to remove one of your opponent’s pieces. They don’t need to, because neither is something a reasonable person would expect on reading the rules.
“En passant” is merely a technical term. It is not necessary for the rules to say explicitly “even though the term comes from the French for ‘in passing’, the pawn completes its move and is then removed only by the capture next move” because that is obvious from the actual rules as stated. Just as it is not necessary for them to say explicitly “even though the term ‘checkmate’ comes from words meaning ‘king dead’, checkmate is achieved as soon as the king is in check and has no way to escape; actually capturing the king is not required”. Or “even though the players are called white and black, it is not necessary for the actual players to be white and black respectively”. Or “even though the knight in some sense represents a man on a horse, a knight’s move can pass over intervening pieces representing things that would be too high for a real horse to jump over”.
There is nothing ill-defined here (at least, not so far as the example you’ve given tells us; there might be errors or omissions I haven’t noticed).
Yes, you are right.
Otherwise we don’t agree at all about this.
But there is a way to decide who is right here. By reviewing some chess engine code, how this instance is handled.
There, rules of the chess are explicitly written down. It would be interesting to see how this is handled and what are the rules.
I would be happy to bet my $100 against your $10 that none of the 10 most widely used chess engines takes a different view of this situation from the one I describe. … Well, actually I wouldn’t, because the nuisance of agreeing details and testing chess engines and so on greatly outweighs the value to me of $10, but in principle I would.
I don’t really see that this would “decide who is right”, though; if people had been writing chess engines back when the rules failed to stipulate that castling has to be horizontal or that promotions have to be to pieces of your own colour, I bet they would mostly have implemented those features in the “expected” way. If there are subtle omissions in the present-day rules, they probably aren’t reflected in actual chess engine code.
I think, chess engines probably do it right.
The question is, how their rules of engagement looks like. Especially, what is the mechanism dealing with the en passant? Is it plain like in the FIDE’s rules?
I don’t think so.
They are different. You see, pure mathematics is like a program in Python written on a sheet of paper. You actually don’t know, if it would run or not.
The same goes for the game rules. Humans do out-negotiate from most situation if not all, but that doesn’t mean that the rules of the game (in this case chess) are without a problem.
I’m not sure I understand your question about “their rules of engagement”. But I took a look at one chess engine’s source. This is Robert Hyatt’s “Crafty”, which at one time was one of the leading engines (others have overtaken it now). Many things are represented as 64-bit bitmaps. Here, accordingly, is its special code for e.p. captures.
First, in a function called GenerateCaptures there is a line that says this:
Everything from “|” inclusive to ”;” exclusive would be omitted if there were no e.p. captures. Second, there is some special-cased code for generating moves when in check (since of course you then only need to consider moves that might get you out of check). Here’s the relevant code:
Without e.p. captures this would be simplified in fairly obvious ways. Third, as well as generating moves there is some code for validating moves (I haven’t looked at how it’s used, but I guess it’s just for verifying that an opponent’s move is legal; I’m not sure why it isn’t good enough to generate all legal moves and see if the given move is among them, since it’s hard to see how efficiency would matter for this). Here’s the relevant bit:
Finally, of course that thing EnPassantTarget needs to be defined. Its definition is simple:
This is basically a wrapper around this:
and this thing needs initializing, setting when a pawn advances two squares, incorporating (since e.p. status is a sometimes-important feature of a position) into the hash function used when storing previously-examined positions, and various bits of bookkeeping (e.g., in the tree search it is convenient to “flip” the position, interchanging the roles of black and white, and the e.p. status is one of the things that needs swapping over). And that’s it.
None of this (of course) involves any sort of reverse-causation where an e.p. capture causes the captured pawn never to have reached the square it nominally moved to. And, aside from the fact of being formalized in computer code, it all seems to me pretty much exactly as clear-cut as in the FIDE rules.
I had a quick look at the source of Stockfish, one of today’s top engines. It seemed fairly similar in complexity, except that Stockfish seems to take some notice of e.p. status in its analysis, which means there’s e.p.-related code that isn’t strictly needed merely because the rules are what they are.
I think you know as well as you do for many pieces of software that have been run. After all, pure mathematics is used all the time by pure mathematicians, and less directly by physicists, engineers, etc. There might be bugs, but so might there be in software that has been used for years.
[EDITED to fix some code-formatting errors and remark that the remaining ones are probably unfixable because AFAIK there’s no good way to stop spaces at the starts of lines being eaten.]
We have 3 somewhat separated questions here.
The first is this about chess. How the rules of chess are defined for chess engines, are they really just a copy of what the official FIDE rules are, and how this is going to play out for some crucial positions.
I argue, that the human rules are a bit vogue and that some engines are very likely well designed, but their rules are a bit different. At least more complete.
The second is about mathematics, how likely everything is consistent there. Very unlikely, if you ask me. But almost certainly very likely all is okay, if I ask you. Even if there are paradoxes, they are so very well hidden, that no surface scanning is going to find one. The ZF has been scrutinized quite deeply and all is okay. That’s your view if I understand you correctly.
The third is about math and software. You are saying, that a lot of mathematics is constantly used by a lot of programs and that program bugs are somewhat a problem, but that there is almost certainly no math bugs.
Here we disagree again. I think there might be some unseen math bugs, too. Probably not in finite simple mathematics, but maybe even there. But quite possibly when things get really complicated.
Perhaps I will not refer to another problem involving infinities here. Just to avoid some unnecessary disputes.