Comments/Ratings for a Single Item

New Metamachy rule-enforcing preset: After brief testing of en passant and initial king move...

I was unable to make any en passant captures using white pawns on ranks 6, 7, and 8. I was able to make normal en passant captures with white pawns on ranks 4 and 5. More interestingly, I was able to make illegal en passant captures with white pawns on ranks 4 and 5. By illegal, I mean that: a black pawn that can be captured normally by a white pawn makes a double-move; White on his next turn is allowed to take that pawn en passant illegally. I was able to make legal en passant captures with black pawns on all squares tested. I was also able to make the illegal en passant captures with black pawns on all squares.

The initial king 2-square move doesn't seem to work.

Will keep testing...

With en passant, the bpr variable for Black's Pawn Rank had the wrong value. For the King's two-space leap, it was checking whether the destination was empty, which works only for potential moves, rather than checking whether a capture had been made. I have fixed these now, and you can test whether anything is still not working.

I just made some more fixes to how the King's two-step leap is handled in the stalemated subroutine, so that only legal moves are displayed.

I made some more fixes to the King's two-space leap in the subroutines for moving the King. They now give informative messages about particular reasons why an illegal move is illegal. Since I used restore to check whether the King was in check, I went back to checking whether the destination space was empty.

King 2-space leap appears to be in order. All legal en passant captures can be made. However, one is still allowed to make incorrect en passant captures.

For example, if a white pawn is on c4 and a black pawn on d5, if White plays c4-c6, the preset still allows Black (incorrectly) to take d5-c4 en passant, removing the pawn on c6.

So, after two rounds of play, the current tournament results are:

[Pos) Name, Pts, #Wins, BS, SB, Black wins]                             

1. Kevin Pacey, 5.5, 5, 11, 13.25, 3; 
2. dax00, 5, 5, 11.5, 11.5, 2; 
3. Carlos Cetina, 4.5, 4, 8, 10.75, 2; 
4. Fergus Duniho, 4, 4, 9, 9, 3; 
5. Greg Strong, 4, 4, 6, 6, 1; 
6. Adam DeWitt, 3, 3, 3, 3, 1; 
7. Jarid Carlson, 1, 1, 1, 1, 1; 
8. Aurelian Florea & wdtr2 & John Davis, 1, 1, 1, 1, 0.

Nice, thank you.  I will get the third round assigned this weekend.  Hopefully I will be able to get a rule-enforcing Symmetric Chess preset working by then but we might have to do without.

Ok, I think we'll be in business for a rule-enforcing preset for Symmetric.  I made some real progress.  The display of legal moves doesn't work yet (the legal move display makes it look like the bishop is a dragon horse), but it terms of what it actually allows, it looks like it is doing the right thing in all cases:

/play/pbm/play.php?game%3DSymmetric+Chess%26settings%3Drules

Greg:

I appreciate very much the effort you make to reinforce the rules of the Symmetric Chess preset, however I wonder if using the preset you suggest will not be more confusing for some people than if we used the entirely uncoded one.

I don't know; it's just a presumption, a guess. In my personal case, I would play without problems with any of those two options.

Certainly, coding the Bishops Conversion Rule is a tremendous challenge.

Hi Carlos,

Sorry, I did not mean to convey that I was done.  Only that I had made progress.  I intend to work on fixing the legal moves display today.

Okay, Greg, sorry for the misunderstanding. Thousand thanks and good luck!

Well, I don't know.  I thought I was getting there but apparently not.  Nothing behaves the way I expect and after about 8 hours of screwing around I've reached my limit.

I don't know exactly what the issue is (and there could be more than one) but part of it seems to revolve around the fact that the rules for Bishop moves are complicated, and I've codified them nicely in subroutines "B" and "b", but the architecture seems to want the 1-line fn defs, which don't seem to support if-then-else, and my attempts to have a def B pass off to a gosub B doesn't seem to work either.

If anyone else wants to look, feel free.  Boiled down, the Bishop Conversion Rule really isn't that hard.  I'm tracking things with 8 flags:

wccanconvert wgcanconvert bccanconvert bgcanconvert wcmustconvert wgmustconvert bcmustconvert bgmustconvert

The first letter, w or b, indicates the player.  The second letter, c or g, indicates the start file of the bishop.  Then there are flags for can convert (which begin the game set) and flags for must convert (which are not set until the other bishop moves without converting.)

I don't know exactly what the issue is (and there could be more than one) but part of it seems to revolve around the fact that the rules for Bishop moves are complicated, and I've codified them nicely in subroutines "B" and "b", but the architecture seems to want the 1-line fn defs, which don't seem to support if-then-else, and my attempts to have a def B pass off to a gosub B doesn't seem to work either.

I tried out your Symmetric Chess preset. The conversion rule seems to be enforced correctly, but conversion moves are not displaying as legal moves, and when a Bishop must convert, it is incorrectly displaying illegal moves as legal. As you correctly surmise, this is because you do not have the b and B functions defined.

While functions do not support if-then-else, as such, they do support cond, which works like the ? and : operators. They can also use and, or, nand, nor, onlyif, and unless. You can look at the functions for other divergent pieces, such as the Pawn or the Cannon, for examples of how to handle this. Here are some examples from chess3. If you understand the logic behind these, you should be able to figure out how to handle the Bishops conversion rule.

def C cond cond empty #0 capture (not empty #1) (checkhop #0 #1 0 1) (checkride #0 #1 0 1) and #1;

def P
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
or and islower space #1 checkleap #0 #1 1 1
and <= distance #0 #1 var fps
and > rank #1 rank #0;

Remember that Game Courier evaluates functions from right to left, and many of the logical operators will work with either one or two operands. In the Pawn example, the logical operators are normally taking only one operand. When and receives a lone true value, it lets the function continue silently, but if it receives a false value, it returns a false value and exits. When or receives a lone false value, it lets the function continue silently, but if it receives a true value, it returns a true value and exits. If you still need more help, just ask.

Thanks, Fergus.  Unless I'm missing something, it seems my B subroutine already has all the logic.  Is there some reason I can't delegate def B to gosub B?  Seems odd I should need to describe all the same logic again but in a different way.

Got it!

def B
or alltrue checkride #0 #1 1 1 !== #0 c1 !== #0 g1
or alltrue checkride #0 #1 1 1  == #0 c1 not flag wcmustconvert
or alltrue checkleap #0 #1 1 0  == #0 c1 flag wccanconvert
or alltrue checkride #0 #1 1 1  == #0 g1 not flag wgmustconvert
or alltrue checkleap #0 #1 1 0  == #0 g1 flag wgcanconvert;

def b
or alltrue checkride #0 #1 1 1 !== #0 c8 !== #0 g8
or alltrue checkride #0 #1 1 1  == #0 c8 not flag bcmustconvert
or alltrue checkleap #0 #1 1 0  == #0 c8 flag bccanconvert
or alltrue checkride #0 #1 1 1  == #0 g8 not flag bgmustconvert
or alltrue checkleap #0 #1 1 0  == #0 g8 flag bgcanconvert;

I'll give the whole thing another lookover in the morning to hopefully make sure I didn't miss anything but I think everything is set.

These look like they will work, but they could be optimized better. They repeat the same operations multiple times, and they don't evaluate the most common type of move first. Also, the first or in each, which is the one to be evaluated last, is unnecessary.

The description of the Bishop conversion rule says this:

" for one of the bishops of the player, the first move made with this bishop must be of this special type. "

I take this sentence to mean that if one of the Bishops gets captured before it moves, the other cannot start with a normal move. This doesn't seem very sensible, though, so I am not sure whether my interpretation is correct.

Just to contribute my two cents: when you would keep one flag per Bishop to indicate whether it had been moved (or per square whether the original occupant is still there), which really should be considered a standard feature automatically kept track of in any chess variant, (considering how many variants endow pieces with virgin-only moves), the game state can be ancoded with only a single other flag per player, indicating whether a conversion has already taken place. The rule for a virgin Bishop is then merely that he cannot convert when a conversion was already done, and otherwise must convert when the other Bishops is not virgin (or, since the rule is only applied on a virgin Bishop, when not both Bishops are virgin). Note that the type of move (W or B) can be easily tested from the color of the square ((x ^ y) & 1 if you have separate x and y coordinates, nr*9 & 8 for 0-63 square numbering on an 8x8 board, nr & 1 on 0-71 square numbering on 9x8).

The description of the Bishop conversion rule says this:

" for one of the bishops of the player, the first move made with this bishop must be of this special type. "

I take this sentence to mean that if one of the Bishops gets captured before it moves, the other cannot start with a normal move. This doesn't seem very sensible, though, so I am not sure whether my interpretation is correct.

I have asked Carlos about this and, if one bishop is captured before either has moved, then the other bishop may convert but is not required to.  I'll edit this page to make it a little more clear.

That certainly makes more sense to me. One could still wonder about the case where the first-moved Bishop does not convert, but is captured before the second moves. The situation this gives rise to is not really any different from the one where it was captured before it moved. And you would need extra game state to distinguish the two.

I guess you need extra game state anyway, because a Bishop can move and return to his starting square without converting. The other Bishop must then convert, but from the board position you cannot see which of the two is the 'other' Bishop.

Possibly the cleanest solution to everything is to implement this by piece-type changing: start both Bishops as Dragon Horses. When a Dragon Horse moves, it 'promotes' to Bishop, and as a side effect, depending on how it moves, the other Dragon Horse (which must still be on its starting square in that case if not captured), promotes, either to Wazir or to Bishop. If a Wazir moves it always promotes to Bishop. All game state is then encoded in the board position.

Here are some optimized versions of the B and b functions:

def B 
== #0 c1 
and flag wccanconvert 
or and == #0 g1 flag wgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or color #0 nor flag wcmustconvert flag wgmustconvert;

def b
== #0 c8 
and flag bccanconvert 
or and == #0 g8 flag bgcanconvert
and checkleap #0 #1 1 0
and empty #1 
or and checkride #0 #1 1 1 or not color #0 nor flag bcmustconvert flag bgmustconvert;

These do the regular Bishop move first, because that's what the Bishop will do most of the time. This can be done when neither mustconvert flag is set or when the Bishop is on the opposite color from the one it starts from. So, if a White Bishop is on a dark square (color = 1), or a Black Bishop is on a light square (color = 0), it can move as a Bishop. Testing for color #0 is quicker than testing for == color #0 1, and testing for not color #0 is faster than testing for == color #0 0, though they are a little bit more obfuscated. With regular Bishop moves out of the way, the function uses a series of breaking conditions to test whether a conversion move is possible. It first tests for conditions common to both conversion moves, testing for the less expensive one first. Also, given that these functions will frequently be used in testing whether a Bishop is attacking a King, including empty #1 as the first condition of the conversion move saves it from the trouble of checking for anything else when used for that purpose. It then tests whether it is legally converting from the g square, and if not, it uses a series of breaking conditions to test whether it is legally converting from the c square.

Thanks, Fergus and Carlos.  I have jury duty this morning, but I will try to get the preset updated after.  But I've been sick and I'm not sure how long I will be there today so we'll see.

What about the continuation of the tournament? Are there any other games going on?

No, the games are complete.  Was finishing the preset for Symmetric, and now I've been sick for almost a week so the preset is still unfinished and next round games are still unmade.  Hopefully soon.

Thanks for the info!... I hope your health improves!...