Looking for C developper

[Greg Strong]

(I don't know what you mean by Sven's ep rule, but it seems there would be some special-casing here too.)

Actually there is no "Sven's ep rule" in the context of Marseillais Chess at all, I did not come up with any rule change proposal, I became aware of Marseillais Chess only 10-15 minutes before I posted a comment yesterday. HGM clearly refers to that posting where I quoted chessvariants.org regarding a possible ambiguity in the e.p. rule. My intention was just to specify that e.p. rule prior to writing engines for it, not to say how the rule should be defined.

Sven

Oops! I thought I had read the whole thread but somehow I overlooked your post

According to Pritchard's Enclopedia of Chess Variants the rule is clearly defined: "En passant is legal if the opponent moved a pawn two squares on either of his moves but the capture must be made at once. However, if the opponent made two two-sqauare pawn moves, both pawns can be taken e.p. This last rule is credited to Alekhine by F. Palatz in an article on the subject (LEC Sep 1928.)" I don't have his Popular Chess Variants, but it was published more recently (2000 vs. 1994.) The stated rule from the Encyclopedia makes sense to me, and was credited, at least partially to Alekhine, so I'd be inclined to go with that.

[Greg Strong]

Interesting... I'm not sure simply having a King capture in the second step return -INF will do it.

You are right. King capture in the second half-turn should not return -INF, but the null-move score.

The question, however, is how to reduce the null move. After a null move in the first half-turn you would certainly want to reduce the second half-turn away, i.e. increase the turn variable by 2. It is coneivable that you are facing a threat that would make this null-move fail low, but which you could solve in your first half-turn. Null-moving in your second step then might still deserve a reduction, but probably a lower one than on a null move that failed high in the first half-turn. When the first half-turn would check (i.e. King capture in the second half-turn) the null move you are forced to play in that second half-turn should not be reduced at all.

A ply is really a quarter-move in this game, and it seems reasonable to iterate, extend and reduce the depth in pairs of ply. A scheme where you would reduce the null move on the first half-turn by 4 ply (in addition to consuming your own two ply), but not reduce a null move in the second half-turn (so you could return its score when you discover King-capture later) might be workable.

Ok, this makes sense to me and would probably work quite well. Doing null-move with no reduction will slow it down quite a bit, but you wouldn't expect a double-move variant to see very deeply (and it wouldn't need to see very deeply to easily smoke most human opponents )

Quiescent search - I was thinking: consider all non-checking captures for a player's first move, and, for the second move, consider all captures and the (non-capture) move of the piece that captured in the first move back to its starting square (thereby considering the possibility of rifle capture, which is an important element of this game.) Obviously this isn't perfect, but should be pretty good.

[carldaman]

Whether Elo is gained or lost by improving play in closed positions depends on who the opposition is, doesn't it?

Only human players will care about and benefit from improved play in closed positions. Such an engine may well score better against humans than ever before. Losing Elo against other engines can be largely irrelevant in this context (although I'd agree that no Elo loss would still be preferred), as long as the human end users get a more well-rounded and realistic analysis and sparring partner.

If you manage to write an engine that can avoid anti-computer chess when playing against a human, it can probably exploit it against another computer.

That would be an interesting project. Difficult, but interesting.

Actually, if an engine could play closed positions really well, then it should not necessarily avoid anti-computer chess vs humans. Such an engine would be of value to human players.

[hgm]

The stated rule from the Encyclopedia makes sense to me, and was credited, at least partially to Alekhine, so I'd be inclined to go with that.

So what if the e.p. square was occupied in the second leg? Can you capture both the piece on in and the Pawn in your first step?

[Greg Strong]

The stated rule from the Encyclopedia makes sense to me, and was credited, at least partially to Alekhine, so I'd be inclined to go with that.

So what if the e.p. square was occupied in the second leg? Can you capture both the piece on in and the Pawn in your first step?

Good question! That situation isn't mentioned, but I'd say yes. It doesn't say you can't, and I think this goes along with the spirit of the rule. If a player really wants to make sure his pawn isn't captured e.p. he can still do it but it costs him both moves (making two single-steps.)

[hgm]

OK, I pushed a version of XBoard to hgm.nubati.net that implements a -fischerCastlings volatile options (no argument). This forces the internal Fischer-castlings flag on with any variant (where before was set only during FRC and CRC games). There is a checkbox for this in the New Shuffle dialog. The setting remains valid until you select a different variant.

So Seirawan960 can now be played by starting XBoard as

xboard -variant seirawan -shuffleOpenings -fischerCastling

or, interactively, by first selecting Seirawan from the New Variant dialog, and then ticking Shuffle Openings and Fischer Castling from the New Shuffle dialog.

I have not extended the shuffle routine yet to involve the holdings. It is a bit tricky to make a general algorithm for that if we don't want to allow all pieces to end up in the holding. The shuffle routine should be applicable to arbitrary variants. Not involving holdings seems the best default in general, although it is not optimal for Seirawan.

There was a bit of a nasty interaction between Fischer castling and Seirawan gating: with Fischer castling the from-square of King or Rook might not end up empty, so that you cannot gate there. So I had to adapt the legality testing for gating moves. Note that I adopted the interpretation that you can gate onto squares that the King or Rook pass over during castling. E.g. when you start with Kd1, Re1 then O-O would move Kd1-g1, passing over e1. This is OK in Chess960, because the Rook is not supposed to interfere with the castling, being involved in it. But if you would gate a Hawk (say) onto e1, I assumed that the Hawk will only appear after the castling has been completed, and not already when you 'lift' the Rook. This interpretation seems most compatible with the Seirawan rule that you are not allowed to 'pass through check' during gating. (E.g. when in check by a black Qa1 white would not be allowed to play Ke1-f1/E, despite the fact that after that move Ee1 would block the check.)

I did not implement shuffling of engine-provided initial-positions yet, nor setting of the fischerCastlings option automatically from loading a FEN that specifies such castlings.

[Sven]

The stated rule from the Encyclopedia makes sense to me, and was credited, at least partially to Alekhine, so I'd be inclined to go with that.

So what if the e.p. square was occupied in the second leg? Can you capture both the piece on in and the Pawn in your first step?

Good question! That situation isn't mentioned, but I'd say yes. It doesn't say you can't, and I think this goes along with the spirit of the rule. If a player really wants to make sure his pawn isn't captured e.p. he can still do it but it costs him both moves (making two single-steps.)

The spirit of the rules of Marseillais chess could also be understood such that each single move itself ("leg" to use HGM's wording) is a standard chess move. But after White's d2-d4/Qd1-d3, for instance, Black's e4xd3 e.p. would capture two pieces at once: Pd4 (captured en passant) and Qd3 (captured just because the queen happens to be on the e.p. target square), and this is not like standard chess. You can define the rule like that, or you can define it differently, but at least you need to define it (and there needs to be consensus about it of course) otherwise the rules are ambiguous and leave room for interpretation. That was the main point of the "chessvariants" link I quoted in a previous posting: clean up ambiguities.

Would the following be a possible "compromise solution" (text based on Wikipedia entry, with my additions in bold)?

"En passant capture is allowed even if the opponent moved the corresponding pawn on the first move of the previous turn. However, en passant capture must be made on the first move of the turn. When two pawns can be captured en passant after opponents move, both of them can be captured. As a further restriction, en passant capture is not allowed if its target square is not empty."

This would keep the "spirit of the e.p. rule" in general while avoiding to add a "non-chess move" that captures two pieces at once. In case of my example above, Black could still capture the Qd3, of course. And the blocking piece is always at least a minor piece, so capturing "only" a minor piece but not an additional pawn should not hurt.

What do you think?

The other proposal of allowing en passant capture after pawn double steps in the second leg only is fine for me as well, and even more simple than my proposal.

EDIT: Maybe this sub-thread should become a separate thread about Marseillais Chess, provided the OP agrees?

Sven

[hgm]

I now also pushed an XBoard version that detects castling type and does shuffling. I made these features part of the FEN reader. So they also work when you configure XBoard through a -loadPositionFile, or when the user pastes a FEN onto the board. For this I have extended the FEN standard with the symbols <, > and ?.

The FEN

<rnbqkbnr>/pppppppp/8/8/8/8/PPPPPPPP/<RNBQKBNR> w KQkq - 0 1

will be interpreted as a FEN that should be subject to randomizing. In particular the back-rank will be shuffled, because it is enclosed in <>. (Currently no other uses of <> as enclosing both entire back ranks are implemented in XBoard!) The shuffling will not involve King and Rooks, however, because the FEN specifies castling, and in the setup as given before shuffling thi sis normal castling. So in fact pasting this FEN as a startposition for variant normal makes you play wildCastle.

But with

<rkqrbbnn>/pppppppp/8/8/8/8/PPPPPPPP/<RKQRBBNN> w KQkq - 0 1

the position before shuffling obviously does not have orthodox castling. So Fischer castling is implied, and the shuffling will also involve King and Rooks, while -fischerCastlings will be set.

In variant seirawan the FEN

<nrb?kbnr>/pppppppp/8/8/8/8/PPPPPPPP/<RNB?KBNR>[QHEqhe] w KQkq - 0 1

(where n and r on a8/b8 were swapped to trigger Fischer castling) would cause a randomly picked Seirawan2880 position to be loaded; the ? causes a random piece to be taken out of the holdings and placed on the indicated location on back-rank before shuffling. After shuffling all back-rank pieces will be assumed virgin in Seirawan Chess. (The <> device is only intended for generating start positions.)

[Evert]

Awesome!

I'll update to the new version and give it a go. Will the "shuffle FEN" work if I send it though the setup command?

[hgm]

Indeed, because I implemented it in the FEN reader that should work as well. And even then it would obey the option -defaultFrcPosition, as it calls XBoard's shuffle routine which does.