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.
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.