Comments/Ratings for a Single Item

In the following game log, the preset won't let me castle kingside as White, which I believe is a legal move:

GAME Code has become more strict about how it handles an insufficient number of arguments to a subroutine. To include optional arguments, you now need to copy values from the subargs array. So, I rewrote the subroutine to do that, and it now works.

@ Fergus:

In the following game log, the preset won't let me castle kingside as White, which I believe is a legal move:

https://www.chessvariants.com/play/pbm/play.php?game=Fischer+Random+Chess&log=panther-cvgameroom-2023-6-700

I didn't mention it earlier, because I got sidetracked, but code is now in place for reconstructing the original position for games that lost this information when PHP changed its randomization algorithm. This seems to have happened in 2009. Games since that time store the original position in a constant, but older games relied on using a seed to guarantee the same selection of random numbers. I went through all the older games and did a lot of debugging to get things to work right. It did not work for a few games that were too short to provide enough information, but it should be working for most past games that didn't include the position in a constant.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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;

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.

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;

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.