Comments/Ratings for a Single Item

Fischerandom Chess email Club (FRCEC) ratings for 
SchemingMind players.

The table below lists the FRCEC ratings for the top 15 
club members that are also members of Chess Variants, but do 
not represent rated games exclusively played in the Game Courier. 

FRCEC members can play their games via plain text
email, the E4 Emailchess Club chess server, Chess Variants
or any other graphical interface that currently
supports FRC in the net. 

See more details on these choices in our website at:
http://frcec.tripod.com


FRCEC ratings for Chess Variants members as of October 30, 2004:

Rank	Rating	Member Name	Country		Wins-Loses-Draws
1	1582	José Carrillo	Puerto Rico	16-7-4
2	1536	David Symoens	France		2-0-0
3	1530	Marc Wakeham	Wales		2-0-0
4	1516	Abhay Kumar	India		2-1-1
5	1514	Jean-Pierre Avy	France		4-4-0
6	1514	Mark Havrilla	USA		3-2-1
7	1494	David Atkinson	Canada		3-4-0
8	1486	Gregory Strong	USA		0-1-0
9	1484	Martin Yates	USA		0-1-0
10	1481	Raúl E. Palacio	Argentina	2-4-0
11	1472	Juan Izquierdo	Spain		0-2-0
12	1470	José Sánchez	Costa Rica	0-2-0
13	1432	Peter Leyva	USA		0-5-0
14	1422	John Richardson	USA		1-6-0

                 

To see FRCEC's Top 20 players ratings go to:
http://frcec.tripod.com/FRCEC_Top20.htm

To see a list of all FRCEC's members and their ratings
go to:
http://frcec.tripod.com/Club_Members.htm

If you are not a member of FRCEC and want to join our
Fischerandom Chess Club, send an email to:
frcec-subscribe@yahoogroups.com

To visit FRCEC's homepage, go to:
http://frcec.tripod.com

I was reading about GAME Code in the Developer's Guide, and following its
advice I looked at the Pre-Game code for FRC.  It appears that this preset
does not generate the 960 starting positions with equal probability.  Of
the 960 possible positions, 216 have the white king starting on b1 or g1,
336 on c1 or f1, and 408 on d1 or e1.  But the preset places the king on
these six squares with equal probability.

The easiest way to generate all 960 positions with equal probability is to
place the bishops first, then the queen and knights, and finally the king
and rooks.

Suppose we place the bishops first. There are 4 squares available to each bishop, and therefore 4*4 = 16 ways to place the pair. Next we place the queen on one of the 6 remaining squares. Then the knights; there are 5*4/2 = 10 ways to place the two knights on the five remaining squares. Finally three squares are left for the king and rooks, and there is only 1 way to place them, since the king must be between the two rooks. Thus there are 16*6*10*1 = 960 possible positions.

The important point is that, in the above counting, the number of placements available to any given piece type is independent of where the preceding pieces were placed. For example, once the two bishops are placed, there are 6*10 = 60 ways to place the remaining pieces, and this is true whether the bishops were placed on a1 and f1, or on d1 and e1, or wherever. Thus, by placing the bishops first, we select one of 16 classes of positions, with the same number of positions in each class. It is therefore 'safe' to place the bishops first.

By contrast, if we place the king first, then the number of possibilities for the remaining pieces depends on where the king is placed. If the king is on b1, then one rook must be on a1, and the other can be anywhere from c1 to h1. Thus with the king on b1 there are 1*6 = 6 ways to place the rooks. But if the king is on c1, there are 2*5 = 10 ways to place the rooks, and if the king is on d1, there are 3*4 = 12 ways to place the rooks. (Also the number of possibilities for the bishops depends on how the preceding pieces are distributed between the two colors of squares.) By placing the king first we select one of 6 classes of positions, but the various classes contain different numbers of positions, and therefore this method skews the probabilities.

A better logic in the pre-game of the preset to give an equal chance to all 960 FRC positions is this:

drop B any a1 c1 e1 g1;
drop B any b1 d1 f1 h1;
drop Q any a1 b1 c1 d1 e1 f1 g1 h1;
drop N any a1 b1 c1 d1 e1 f1 g1 h1;
drop N any a1 b1 c1 d1 e1 f1 g1 h1;
drop R left a1 b1 c1 d1 e1 f1 g1;
drop R right b1 c1 d1 e1 f1 g1 h1;
drop K all a1 b1 c1 d1 e1 f1 g1 h1;

I had forgotten about the criticism of my randomization algorithm until I read it again today. The criticism is that my algorithm does not give equal probability to each combination. My intuition was that this criticism is false. I have now proven it to be false with a program that goes through every single combination of my algorithm, counting the frequency of each combination. The results demonstrate that my algorithm allows for precisely 960 combinations, encountering each one exactly once. The results are here, and the PHP code can be read here.

Oh, wait. I understand the criticism now. By beginning with the King, it gives equal probability to six different sets of combinations, but these sets of combinations differ in size. When the King is toward the edge, the sets are smaller than when the King is toward the middle. So, any particular combination with the King in the middle is less likely to be chosen than any particular combination with the King towards the edge.

According to statistics I just took, the Queen appears on each space exactly 120 times, the Knight and Bishops appear on each space exactly 240 times, and only the King and Rooks vary in the frequency that they appear on each space. So, to assure equal probability of each combination, the Queen, Bishops, and Knights should go on first. The order these are placed relative to each other doesn't matter. Then the three remaining spaces should be filled in with Rook, King, Rook. So I have changed the code to the following:

  drop B any a1 c1 e1 g1;
  drop B any b1 d1 f1 h1;
  drop Q any a1 b1 c1 d1 e1 f1 g1 h1;
  drop N any a1 b1 c1 d1 e1 f1 g1 h1;
  drop N any a1 b1 c1 d1 e1 f1 g1 h1;
  drop R first a1 b1 c1 d1 e1 f1;
  drop K first b1 c1 d1 e1 f1 g1;
  drop R last c1 d1 e1 f1 g1 h1;

> The order these are placed relative to each other doesn't matter.

Well, it is important that you do the Bishops before the others (which you do, so no problem there), or at least before you do two others. For instance, if you would do the two Knights first, you would have too large a probability that they are on the same color (3/7, in stead of 2/5).

WinBoard can shuffle any variant, the algorithm I use there first places all pairs of color-bound pieces on opposite colors, and then does the rest.

I think there is something currently wrong with the way this preset is handling castling. Here is an image from a test game in which I tried castling. White's position shows the files that the King and Rooks began in, and Black's shows the position after castling. Although this is a proper castling position for Queen-side castling, the King castled with the King-side Rook (whose usual position is actually filled by the Queen here). So, castling should have worked by the King moving to g8, and the Rook going to f8, which would have still been impossible with these spaces filled by the Knight and Bishop. I happened to be checking this out, because of another problem with this preset, which is that it does not display legal castling moves when displaying other legal moves.

Here, White has just done a proper Queen-side castle:

Here, I took back that move and tried King-side castling. The King and Rook ended up in the same position as for Queen-side castling.

It's also notable that in the position just before these two different moves, King-initiated castling did not work, and these castling moves were both initiated by moving the Rook to the King's space. So, I'll have to rework how castling works in this game.

Thank you for checking - I meant to test the three games we'd be playing in round 1 but hadn't gotten to it yet.  If it's not a quick fix, I can substitute something else.

When I moved the King to the correct space for King-side castling, it worked. So the main thing to do is to prevent some illegal castling and to display castling moves among the displayed legal moves.

Castling is now working properly. I just had to change the conditions under which the Rook was allowed to castle by additionally checking whether it was coming from the correct space for castling in the direction it was going. Now I need to get it to display legal castling moves. This diagram shows legal King-side castles made by moving the King-side Rook. Moving the Queen-side Rook to the King's space resulted in the error message that a piece cannot capture a piece belonging to the same side.

Castling moves are now displayed among the legal moves. I added a castlepos subroutine to indicate whether castling was possible, and I gave the game its own stalemated subroutine. There was no need to change the checkmated subroutine, since castling is never legal when the King is checked, and that subroutine is used only when the King is in check.

Castling works by having the King or Rook move to the space it would move to during castling, so long as this would otherwise be an illegal move. When the King and Rook are each occupying the position that the other piece would go to during castling, castling may be done by moving either one to the other's space, but in displaying legal moves, only the King moving to the Rook's space gets displayed. The castling move is displayed as a Rook move when it involves the Rook leaping over the King, because the King already started in the spot it would go to during castling, or the King is in the spot the Rook will move to, which is only one space away from the King, and the Rook is not in the space the King will move to.

It would never happen that castling was impossible because both the King and Rook started out in the spaces they would move to while castling. In the position shown below, for example, the King started out in the g file, and one of the Rooks started in the f file. Although this is a position that the King and Rook would take for King-side castling, it is the Queen-side Rook that is in the f file. The King can castle with that Rook by moving to the c file, and if the f Rook moves out, the King-side Rook can castle with the King by leaping from the h file to the f file.

I have been working on code for analyzing the moves in a game of Fischer Random Chess to calculate what the original position was. It's mostly working fine, but there is one problem that is proving difficult. When a player castles by moving a King two or more spaces, and it doesn't yet know it is a King, it doesn't know this is a castling move, and it doesn't complete the castle. Later on, the Rook may try to move from a space it was never moved to. This error can cause a cascade of errors that screws up the calculation.

What I do know is that if a piece tries to move from an empty space, it must be a Rook, and a castle has previously happened. I might then reanalyze the previous moves for a castling move that would have put the Rook on that space. Since castling is not allowed when there is a piece between the King and the Rook, the Rook would have to be the first piece in the direction that the King moved.

I suppose it is also possible to do some further analysis on a move that is potentially a castling move made by a King. If I knew that the piece was a King, or something about the position indicated that it could not be a Rook or Queen, then I would know it is a castling move right away.

I have been working on code for analyzing the moves in a game of Fischer Random Chess to calculate what the original position was.

It depends entirely on the move notation you start from. In PGN game records castling would be written as O-O or O-O-O, so you would always know whether a move is a castling. Even in other notations for FRC castling is usually not written as the King step, because this would cause ambiguity when the King only moves a single step. In the UCI protocol for communicating with chess engines castlings are therefore encoded as the King 'capturing' the friendly Rook it wants to castle with. That would also make in unambiguously a castling, when there were no moves from or to the destination square before.

I don't think the problem can be solved in general. The first move of a Knight or Bishop could come from two locations on the back rank. And if both these locations are visited by an enemy piece before the occupant of the other moved (or the game finished before the other moved), you would never know which of the two it was.

It depends entirely on the move notation you start from.

It uses simple algebraic notation that always includes both coordinates but doesn't necessarily include the piece, and all it needs for castling is the move that would otherwise be illegal for one of the two castling pieces. So, castling gets done with only one written move instead of two. When the Rook initiates castling, this is easily spotted, because it moves to an occupied space or hops over an occupied space, and that occupied space is where the King is. But when the King initiates castling by moving two or more spaces, this could also be a Rook or Queen move. If the player used piece notation with the move, there wouldn't be any problem, but some players left out the piece notation in the move, because Game Courier didn't require it to know what to move.

I don't think the problem can be solved in general. The first move of a Knight or Bishop could come from two locations on the back rank. And if both these locations are visited by an enemy piece before the occupant of the other moved (or the game finished before the other moved), you would never know which of the two it was.

No, there are other methods for identifying pieces besides noting how the piece moved. Pieces are associated with binary numbers corresponding to which potential pieces they might be. When all pieces of a particular type have been identified, the bit for possibly being that piece will be turned off for all the other pieces. By this means, process of elimination is used to identify pieces that never moved. Also, the two Bishops are distinguished from each other, as they go on different colors, and since Black's pieces mirror White's, a move by a piece on either side is enough to identify it for both sides.

It turns out that the particular log I was analyzing may have an illegal move in it. As far as I can tell by my analysis, one player moved a previously moved Rook to his King's space, and the King was not on a space that Rook would move to while castling, though it was a space the other Rook would move to while castling. Since the other Rook was adjacent to it, moving there with it would have been a legal castling move. The result of this move was that the player captured his own King, and this caused errors down the line.

According to the comments in the game, the King's were on the d file, and the Black player was expecting the White player to make the move that appears to be illegal. White's previous move had moved the Rook to the space it would go to while castling, and Black had expected White to castle on that move. So, maybe, I deleted the wrong move from a two-move castle that was made without rule-enforcement. However, changing it to that has changed the opening position, now placing the King on the g file. This is because my code does not yet account for a King castling by moving to the Rook's space, which is how this castling move needs to be written. I will deal with that tomorrow. In the meantime, I will change it back.

That log is now properly analyzed for its opening position. I added code that would recognize a castling move made by moving a King to a Rook's space or by hopping over the Rook. I also corrected the instructions for how to castle in the Notation section. It now mentions that the King may move to the Rook's space or hop over it to castle.

I have also added some code that turns off the Rook bit for the pieces starting on each side of a Rook when a Rook has been identified, since the two Rooks may not start out adjacent to each other.

I don't understand this exercise. Game Courier knows what the opening position is or you wouldn't be able to open a log and replay the moves. What am I missing?

I don't understand this exercise. Game Courier knows what the opening position is or you wouldn't be able to open a log and replay the moves. What am I missing?

This preset originally just stored the seed for randomizing the pieces. Constants were not yet a part of GAME Code, and they were not being used to store the position. When PHP changed the algorithm used for randomization, this broke all past games. To prevent this from happening in the future, I added constants to the language and used them to store the opening position in the log. This did not fix older games, though.

An update to PHP included a flag for srand() that allegedly tells it to use the old randomization algorithm. Despite using this flag with srand(), this has not fixed old logs. So, the only solution is to calculate the original position by analyzing the moves.

When a player castles by moving a King two or more spaces, and it doesn't yet know it is a King, it doesn't know this is a castling move, and it doesn't complete the castle.

I have addressed this in the following manner. First of all, every space on ranks 1 and 8 are flagged. Whenever a piece moves, its origin and destination are both unflagged, and whenever a castling move is made, all spaces on the back rank for that player are unflagged. This guarantees that castling moves can be made only by previously unmoved pieces, and that each player can castle only once. When a King castles by moving two or more spaces, it moves to the c file or to the g file. That means the spaces in between are empty, and the Rook will be the a, b, or h file. It is assumed to be a castling move if the moving piece has the King bit set but does not have the Queen bit set, and if the other piece has the Rook bit set. In this situation, it seems likely that it is a castling move.

However, it is conceivable that the Rook is on the a file while the King is on b, and the piece moving to c is a Rook. I could check that the a piece is not a Rook. This would make the likelihood of it being a castling move stronger. Or it may be enough that either a is not a Rook or the moving piece is not a Rook. If a is not a Rook, b could not be the King and the moving piece could not be a Rook, since the King goes between the two Rooks. Likewise, if the horizontally moving piece is not a Rook or a Queen, it must be a King.

Doing it this way, there is still a chance that an actual castling move could be interpreted as a Queen move. Usually, though, the player has to move enough pieces out of the way before he can castle by moving the King to the c or g file. This should usually give enough time for the Queen to be identified.

Today I modified castling as I described earlier. I also rewrote a big chunk of the code. It is a do loop that includes various tests for modifying piece values. It loops as long as it makes changes. If it goes through once without making any new changes, it stops. I used to run an earlier version of this loop after all the moves. But to speed up the identification of pieces, I placed it after each move. This also replaces the code that makes further changes based on the particular move just made. It includes two main types of tests. One type tests whether the possible pieces of a particular type matches the number in the game. If so, it converts these possible pieces to actual pieces. The other type of test checks whether all of a piece type have been found. If so, it turns off the bit for that piece in any remaining pieces for which that bit is still set. Besides these, there are some tests that try to identify the King after both Rooks have been found or try to identify the Rooks after the King has been found. These come in the same two types. One test identifies the actual piece, and one turns off the appropriate bit in other pieces.