A nice read. I've been playing around with my own chess program and trying to implement a lot of chess variants like Double Chess and 7 Queen's Chess.
Chess invariants
41–50 of 67 posts
Re: Chess invariants
#42The historical rules also left ambiguous promotion to the opposite color: https://chess.stackexchange.com/questions/8291/pawn-promotio.... This rule was clarified later to restrict to the same color.
Re: Chess invariants
#43This is just the beginning. You could create more and more advanced invariants. And I am sure that this could be a way to "solve" chess, i.e., prove that it's a draw with perfect play.
doubtful, or at least not useful ones. Like, you could describe some invariant along the lines of "the position is winning for the side-to-move, iff there exists move, such that position' := ApplyMove(position, move) is losing for the (now other) side-to-move". But that's just restating minimax algorithm that people have known for 50 years.
As someone dabbling abit around chess engine development, I'm very often impressed by the many intricacies and observations made by people who pushed the envelope. It just doesn't sound plausible people wouldn't have discovered these killer invariants by now if they existed
Re: Chess invariants
#44> Chess is a lot trickier than it looks. It has so many rules: castling, en passant, pawn promotion, pinning, the discovered check, and the deadlock case of stalemate. Nit: Pinning and the discovered check are not really rules, but rather names of tactics.
Well, if a piece is pinned it's illegal to move it. Rule 3.9.2: No piece can be moved that will either expose the king of the same colour to check or leave that king in check.
That rule doesn't mean it's illegal to move a piece that's pinned. It just means that it's illegal to move it to a square that would expose the king. For example a pawn that's pinned vertically can still push forward, it just can't capture diagonally.
That's why treating colloquial concepts like "pinning" as though they are rules in and of themselves is not really precise or productive.
Re: Chess invariants
#45While I think everything written in this post is correct, what really is starting bothering me is this over-focus/attention on data even when what you want to express is behavior, let me explain: The post talks about "transition invariants" that should be somehow different from "state invariants" yet it describe them as: > These are predicates over a > pair ... i.e. it still is about state, but I find it much more us…
> instead of thinking about how state transition you focus on what the program is allowed to perform
The state transition is what the program is or isn't allowed to perform. The state they're talking about in the invariant isn't the program state, it's the game state.
Re: Chess invariants
#46Earlier quoted context omitted.
That's a consequence of not being allowed to put yourself in check (by any means).
The only way to put yourself in check is by moving.
You can put yourself in check by moving the king. That has nothing to do with pinning. Adding a rule for pinning is redundant.
Re: Chess invariants
#47This is just the beginning. You could create more and more advanced invariants. And I am sure that this could be a way to "solve" chess, i.e., prove that it's a draw with perfect play.
doubtful, or at least not useful ones. Like, you could describe some invariant along the lines of "the position is winning for the side-to-move, iff there exists move, such that position' := ApplyMove(position, move) is losing for the (now other) side-to-move". But that's just restating minimax algorithm that people have known for 50 years. As someone dabbling abit around chess engine development, I'm very often impr…
I agree it's hard and non-obvious. If it wasn't then chess would have long been solved by now.
Let's start from the other end. Just a pawn and two kings. It's possible to describe some quite succinct rules for when that's a draw versus a win for the side with the pawn. Agreed? Club players know these by heart. You could write that doen as invariants. As long as the side with the pawn stays inside the "green zone" of the state space, there is nothing the other side can do to void mate. And vice versa, if the game is in the red zone and the other player manages to stay inside that red zone, there is nothing the side with the pawn can do to win. Those areas of the state space, green and red zones, can be described as invariants, in contrast to just enumerating them. It's very compact and can easily be checked by a machine that it's correct.
Now let's add a pawn. And another. And a rook perhaps. The more you add, the harder the condition is to describe, but we live in the age of billion-node-sized neural nets, we have the resources. Eventually you get all pieces on the board, and if the starting position satisfies the draw invariant, that's it. And likely the 960 freestyle chess positions too.
Re: Chess invariants
#48So many of these invariants are redundant and so few of them encode any of the interesting rules of chess.
Re: Chess invariants
#49[dead]
Re: Chess invariants
#50[flagged]