Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
I think the counter fields are of more interest to players than engines. The 50move counter is not much use to an engine without the hash history and that requires EPD with move stream or PGN. History is a thing, and raw epd doesn’t have it.
Castles is reversible in the sense that the king and rook could wriggle themselves back where they started from, and thus repeat the position, albeit one in which castles is no longer available. Has such a case ever been fought out in real life? Draw or not draw. Not heard of one.
hgm wrote: ↑Wed Feb 19, 2020 8:08 pm
It depends on what positions the engine can (or is willing) to handle. If it has no problem playing with 15 Queens, it would be a waste to prevent the user from exercising that capability. If its piece-list structure (say) would only allow for 3 Queens max, you will be forced to refuse the position. For UCI engines there is no formal way to report errors, though. You could use an 'info string' response in the hope that the GUI would show that to the user, but if that goes unnoticed, it is unavoidable that the GUI from that point on will assume a different position than the engine. UCI engines can also not resign. The only sure way to catch the user's attention is to make the engine quit. It isn't a bug, it is a (UCI) feature!
I must admit that even CECP has no formal way to complain against invalid positions loaded into the engine (so that the GUI could switch back to the position before it had before, as it would do on an illegal-move complaint). The specs recommend to just reject any subsequent move as illegal after loading an illegal position. And CECP offers more forceful ways to present a message to the user.
I don't understand you point. GUIs do not allow users to just freely type a (broken) FEN. Users use the mouse to select, move pieces etc. That already eliminates a lot of possible broken strings, as for stupid positions without kings or with several of same color, it's the GUI responsibility to perform user validation.
Again proof that, contrary to your claims,UCI is the correct design and CECP is not.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
To check the position for legality, the GUI would have to be aware of the rules of the game. E.g. in Suicide Chess positions without King (or with multiple Kings) are quite legal (and common). Whether castling rights should be considered correct or faulty would depend on whether one is playing Chess960 or not.
Requiring all existing GUIs to contain dedicated code for validating positions for a variant that only a single engine can play would be a very inefficient solution to the validation problem.
I am not sure what 'claims' you refer too. Seems to me I just explained how the protocols work, and I don't see anything there that is incorrect.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
The 50-move rule is not about reversibility, but about progress. Castling doesn't bring you any closer to winning the game, other than in the sense that it sometimes can be a good move. But we do not reset the counter on good moves; that would be too subjective. Pushing a Pawn brings it closer to its promotion square, though. Or, more importantly, failing to push any Pawn for an extended time means you are NOT getting any closer to promotion.
That Pawn moves are irreversible is in a sense just a coincidence. Although there would be a real problem in reformulating the 50-move rule when Pawns could also move backwards. Some Chess variants (such as Chu Shogi) have pieces with a decisive promotion that are fully reversible. You would not want to reset the counter all the time when a player is just moving a Pawn back and forth between two squares. A solution would be to compare each position with the position 50 moves earlier, and count the total Pawn advance. If there has been no capture or promotion (which would reset the counter), all Pawns must still be there, and if on the average they would not have advanced any while the reversible counter is also above 50, you could declare draw. But this is rather hard to check. Not taking Pawn advance into account at all would be unsatisfactory, though: many games on the way of being won would then suddenly become draws.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
Always been that way. Was never sure exactly why, but I presume that at least most chess engines get this right. I know Crafty does.
Not sure what you mean by getting it “right”.
If you reset your 50 move counter by treating castling as irreversible, then that’s a contravention of rules of chess and you run the risk of being caught out by a draw.
If you don’t reset (rules of chess compliant) then you run the risk (small but finite) of re-wriggling KR back to the same position. Which is not a draw because of castle status. At this point there’s a bug risk of hash-match draw unless you incorporated castle status into the hash.
I’m going to check mine, because I think I might be doing both those things. 1. Treating castles as irreversible and 2. Incorporating all four castle status in the hash. Which would be dumb. Should be: castles reversible and castle status in hash.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
I think the counter fields are of more interest to players than engines. The 50move counter is not much use to an engine without the hash history and that requires EPD with move stream or PGN. History is a thing, and raw epd doesn’t have it.
Castles is reversible in the sense that the king and rook could wriggle themselves back where they started from, and thus repeat the position, albeit one in which castles is no longer available. Has such a case ever been fought out in real life? Draw or not draw. Not heard of one.
Actually it is. The 50 move half-clock applies without knowing previous positions (which would only be useful for 3-fold repetitions.) For your question, you might get someone to search for a position with king and rook on original squares but no castling allowed. No idea if that is real or not.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
Always been that way. Was never sure exactly why, but I presume that at least most chess engines get this right. I know Crafty does.
Not sure what you mean by getting it “right”.
If you reset your 50 move counter by treating castling as irreversible, then that’s a contravention of rules of chess and you run the risk of being caught out by a draw.
If you don’t reset (rules of chess compliant) then you run the risk (small but finite) of re-wriggling KR back to the same position. Which is not a draw because of castle status. At this point there’s a bug risk of hash-match draw unless you incorporated castle status into the hash.
I’m going to check mine, because I think I might be doing both those things. 1. Treating castles as irreversible and 2. Incorporating all four castle status in the hash. Which would be dumb. Should be: castles reversible and castle status in hash.
I don't reset, since the rules explicit enumerate the moves that can reset the counter (pawn move or any capture). I do factor in castle status in hash table and repetition list, so Crafty would miss the repetition. This seems to me to be one of those potential issues that is not worth worrying about.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
Always been that way. Was never sure exactly why, but I presume that at least most chess engines get this right. I know Crafty does.
Not sure what you mean by getting it “right”.
If you reset your 50 move counter by treating castling as irreversible, then that’s a contravention of rules of chess and you run the risk of being caught out by a draw.
If you don’t reset (rules of chess compliant) then you run the risk (small but finite) of re-wriggling KR back to the same position. Which is not a draw because of castle status. At this point there’s a bug risk of hash-match draw unless you incorporated castle status into the hash.
I’m going to check mine, because I think I might be doing both those things. 1. Treating castles as irreversible and 2. Incorporating all four castle status in the hash. Which would be dumb. Should be: castles reversible and castle status in hash.
I don't reset, since the rules explicit enumerate the moves that can reset the counter (pawn move or any capture). I do factor in castle status in hash table and repetition list, so Crafty would miss the repetition. This seems to me to be one of those potential issues that is not worth worrying about.
Yes, I checked mine to make sure, it doesn’t treat castles as irreversible either. Had the idea I told it different, but whatever.
What you’re doing is right. Position repetition with differing castle status is NOT a draw. So you’re not missing anything, the wriggled but identical piece position will have different hash because of the castles hash inclusion.
Dann Corbit wrote: ↑Thu Feb 20, 2020 12:20 am
I notice something else -- the rule does not mention a castle move which is also not reversible.
I think the counter fields are of more interest to players than engines. The 50move counter is not much use to an engine without the hash history and that requires EPD with move stream or PGN. History is a thing, and raw epd doesn’t have it.
Castles is reversible in the sense that the king and rook could wriggle themselves back where they started from, and thus repeat the position, albeit one in which castles is no longer available. Has such a case ever been fought out in real life? Draw or not draw. Not heard of one.
Actually it is. The 50 move half-clock applies without knowing previous positions (which would only be useful for 3-fold repetitions.) For your question, you might get someone to search for a position with king and rook on original squares but no castling allowed. No idea if that is real or not.
If I get round to it, will make an epd plus move history (as in uci) with artificial move sequence to destruction test draw code
