The post that was quoted here has been removedIts a bit more complicated than I originally thought...
"The FIDE Laws of Chess says in article 9.6:
"The game is drawn when a position is reached from which a checkmate cannot occur by any possible series of legal moves, even with the most unskilled play. This immediately ends the game.""
http://www.e4ec.org/immr.html
To keep the implementation simple, I think RHP should implement only K + B v K, and K + N v K. These are vital.
If Russ and Chris were feeling enthusiastic, I think cases 1 to 4 could be implemented.
The others aren't practical to implement.
K + N + N v K can possibly result in a checkmate, so definately shouldn't be included.
D
Originally posted by RagnorakWhat's the fourth case? I see only three:
Its a bit more complicated than I originally thought...
"The FIDE Laws of Chess says in article 9.6:
"The game is drawn when a position is reached from which a checkmate cannot occur by any possible series of legal moves, even with the most unskilled play. This immediately ends the game.""
http://www.e4ec.org/immr.html
To keep the implementation simpl ...[text shortened]... + N + N v K can possibly result in a checkmate, so definately shouldn't be included.
D
K v. K
K+N v. K
K+B v. K
Originally posted by XanthosNZThat's actually two (or many more) more cases. K+B v. K+B and K+B+B (up to 9 Bishops) v. K both cannot end in checkmate if the Bishops travel on squares of the same color.
KBBK with both bishops being on the same coloured square.
Not likely but a case nonetheless. Isn't it?
There are also 'special' cases, such as the following:
Andrew Buchanan
StrateGems 2002
White to play. What was Black's last move?
So it is a question of which cases are practical to code.
Originally posted by BigDoggProblemIf you had looked at the link I had provided, you'd see a table of scenarios, from 1 to 8.
That's actually two (or many more) more cases. K+B v. K+B and K+B+B (up to 9 Bishops) v. K both cannot end in checkmate if the Bishops travel on squares of the same color.
There are also 'special' cases, such as the following:
Andrew Buchanan
StrateGems 2002
[fen]Bb1k1b2/bKp1p1p1/1pP1P1P1/1P6/p5P1/P7/8/8[/fen]
White to play. What was Black's last move?
So it is a question of which cases are practical to code.
1 to 3 you know.
4 is stated as
King + m * Bishops
m > 0
bishops (if more) stand on the same color
v
King + n * Bishops
n > 0
bishop (or bishops if more) stand on the same color as bishop or bishops on the other side
so programmatically, there is an algorithm to cover the many different cases.
Cases 5 - 8 would have been the special cases, like the one you mention, which I suggested would be impractical to implement.
D
Originally posted by RagnorakThe problem on this site is that links don't look like links. I finally got the linkification extension for Firefox, which fixes this problem.
If you had looked at the link I had provided, you'd see a table of scenarios, from 1 to 8.
1 to 3 you know.
4 is stated as
King + m * Bishops
m > 0
bishops (if more) stand on the same color
v
King + n * Bishops
n > 0
bishop (or bishops if more) stand on the same color as bishop or bishops on the other side
so programmatically, there ...[text shortened]... cial cases, like the one you mention, which I suggested would be impractical to implement.
D
Initially I thought this would be quite a load on the server, having to parse the fen of every game after a submit. However they could considerably reduce the load by only parsing when they know a draw from lack of material is possible. For instance .. add a new column to the game database called "drawround" .. initially it would be set to 19 (the smallest number of moves to reach one of these situations i think) .. if the number of moves in the game is less than this number then no need to parse the fen. On reaching move 19 the fen is parsed and if a draw is not present then the next possible draw round is calculated from the remaining pieces and the db entry is updated. That way the necessity for the fen to be parsed is greatly reduced .. i think there is even some perl code out there that will tell you if a particular fen is a draw, shouldn't be too hard to convert it to php .. or whatever they are using on the backend.
Also, aren't these also instant draws? Anyone know if it is possible to blunder mate in these positions?
N + K v N + K
nB + K v N + K
