Chess960 Computer World Championship

[Reinhard Scharnagl]

You will find a very interesting article of the Frankfurt Chess Tigers on this event at: http://www.chesstigers.de/index_news.php?id=237&rubrik=4
Reinhard.

[Reinhard Scharnagl]

Hi Chess960 Fans,

a) have a look at the programmers info page at: http://f51.parsimony.net/forum204700

b) there is a new Smirf beta (time limited) downloadable now as a Installshield package at: http://de.geocities.com/rsmuenchen

Regards, Reinhard.

[Volker Pittlik]

Hi Chess960 Fans,

a) have a look at the programmers info page at: http://f51.parsimony.net/forum204700
...
Regards, Reinhard.

Can you provide a link to the exact castling rules please?

Volker

[Reinhard Scharnagl]

Hi Volker,

well, here it comes:

shortly spoken the rules for castling are the same as in traditional chess,
if you respect the following (with King and Rook at randomized squares):

1) The positions of King and Rook after a castling are IDENTICAL to traditional chess.
2) Neither King nor Rook are allowed to jump over or capture any third piece during castling.

a) For rules at my own homesite see:

http://www.chessbox.de/Compu/fullchess3.html (German)
http://www.chessbox.de/Compu/fullchess3_e.html (English)

b) Chess Tiger's fine PDF documents could be found at chapter Chess960 (PDF):

http://www.chesstigers.de/download.php

=> Einf?hrung, Startpositionen und Regeln (German)

=> Rules (English)


Regards, Reinhard.

[Volker Pittlik]

Thanks. I just have another question.

Let's assume a FRC game, neither the white king nor rook has moved so far and this position is reached:

[diag]5k2/8/8/8/8/8/8/2K1n1R1 w - - 0 1[/diag]

5k2/8/8/8/8/8/8/2K1n1R1 w K - 0 1.

If I understood correctly in Chess960 white is not allowed to do the g-castling. In FRC it may be allowed.

Has anybody implemented that white is allowed the g-castling in the above position? How let the program know which rule set is valid?

If I haven't overseen something Arena sends a FEN string at the beginning of a new FRC game to the engines where all castlings are allowed. So the engine can find out themself if this is the beginning of a new FRC game or just a test position. But it is not clear which castling rules have to be applied. It seems there is some additional input necessary, something like:

>1:position fen <valid piece placement string> w KQkq - 0 1
>1:castling rules <FRC||Chess960> ?

Or the user must have the opportunity to "tell" the engine which castling rules are valid. Maybe in the ini file by pressing <Alt+1> in Winboard.

Regards

Volker


Regards

Volker

[Reinhard Scharnagl]

Hi Volker,

once upon a time there has been such a confusion created by some 'fans' (I do not want to write names here), who claimed such jumping castlings would not be excluded by the rules. But that is a bad and wrong story.

One proof for that is, that then in traditional chess (which should of course be 100% compatibly included) unknown O-O-O castlings suddenly would become possible:

[diag]1n2k2r/8/8/8/8/8/8/RN2K3 w - - 0 1[/diag]
Fen: 1n2k2r/8/8/8/8/8/8/RN2K3 w - - 0 1


I had watched, that there indeed have been some engines, performing such wrong jumping castlings. Thus it is very important to compare the engines' behaviour to the provided castling examples.

There are no different rules. Chess960 simply is a new and preferred name for FRC (Fischer Random Chess).

Regards, Reinhard.

[Volker Pittlik]

...
There are no different rules. Chess960 simply is a new and preferred name for FRC (Fischer Random Chess).
...

Thanks for clarification. Just a (I hope) last question (sorry if this has been asked before). Let's assume this is a position from an FRC game:

[diag]4k3/8/8/8/8/8/8/1R1K4 w - - 0 1[/diag]

4k3/8/8/8/8/8/8/1R1K4 w Q - 0 1.

Let's assume white's king and rook haven't moved before. If the engine hasn't implemented SAN the command "move d1c1" is ambiguous. It could be a king move or a c-castling. If the king is not placed on the d-file, but somwhere else from e to g there is no problem, because the GUI can always identify it as castling as in e1c1 in the standard variation. Am I totally wrong or does the implementation of SAN solve this problem? O-O-O is always the c-castling.

Volker

[Reinhard Scharnagl]

Hi Volker,

you seem to be watching very carefully. You are now targeting the problem, which I have adressed since years for the protocols (UCI and Winboard) to become compatible with Chess960, to make it easier for GUIs to support it.

The encoding problem raises by more reasons. First it is ambiguous if a King's castling move exactly consists of one or none elementary step. The second problem bases on the illogical demand of the Winboard protocol to differently encode castlings.

1) It would be absolutely compatible and sufficient to encode castling moves by the King's source and destination coodinates, followed by an additional 'k', if the move consists of less than two elementary steps, thus distinguishing (in a way used by promotions) the castling move from simple King's moves or possibly a technical Nullmove.

2) Supporting X-FEN will allow to skip unnecessary distinguishing between 'normal', 'fischerandom' and 'nocastle', because all information needed already is included in the X-FEN string's castling rights part. This corresponds with the fact, that a real Chess960 enabled engine ALWAYS is playing Chess960. It does not need any switching. But instead it has to give the GUI an information of being Chess960/FRC aware.

The Arena GUI actually seems to solve that problem by always using O-O and O-O-O for castling moves. That is a work around, until the protocols will consistently be extended for Chess960, so I hope e.g. for UCI to be completed soon.

Regards, Reinhard.

[Volker Pittlik]

Hi Volker,

you seem to be watching very carefully. ...

Implenting EPD handling taught me to be pedantic . I still cannot decide is SAN solves that problems. I'm going to study http://f51.parsimony.net/forum204700/messages/16.htm carefully and after I solved other problems (what will take some days) I will return to this one.

Volker

[Volker Pittlik]

... I still cannot decide is SAN solves that problems. I'm going to study http://f51.parsimony.net/forum204700/messages/16.htm carefully and after I solved other problems (what will take some days) I will return to this one.

Volker

Instead of establishing a new X-FEN standard I think it would be possible to solve the problems with the given methods. Let's assume this is a position from a FRC game:

[diag]1r1k3r/1p5p/8/8/8/8/1P5P/1R1K3R w - - 0 1[/diag]

Assuming both engines support SAN and EPD it is possible to describe the position and moves without ambiguousness if there were an additonal opcode in EPD description. Let's call this new opcode "FCR" for FRC castling rights. Then the EPD text line for the above position could be:

1r1k3r/1p5p/8/8/8/8/1P5P/1R1K3R w - - 0 1 FCR Qkq;

If the engine is aware that this is a FRC position (what can easily done by reading the EPD text line) the move "Kc1" by White must be King move. C-castling has to be announced as O-O-O. O-O would be illegal and Black could move O-O and O-O-O. Or have I overseen something?

Regards

Volker

[Reinhard Scharnagl]

Hi Volker,

first X-FEN ist absolutly downwards compatible. So an FRC engine has not to switch between different methods.

Second all positions must be descriptable with X-FEN. For this regard the position of White before castling, I wrote this first at http://f51.parsimony.net/forum204700/messages/44.htm.

[Event "SmirfGUI Computerchess Game"]
[Site "CHESSBOX"]
[Date "2005.06.19"]
[Time "10:22:29"]
[Round "Test"]
[White "White"]
[Black "Black"]
[Result "*"]
[Annotator "R. Scharnagl"]
[SetUp "1"]
[FEN "rnbnkqrb/pppppppp/8/8/8/8/PPPPPPPP/RNBNKQRB w KQkq - 0 1"]
1. h4 g6 2. g3 Bf6 3. a4 Qh6 4. Ra3 Bxh4 5. gxh4 Qxh4 6. Qh3 Qxh3 7. Rxh3 Ne6
8. Bf3 d6 9. Nbc3 Ng5 10. Rhh1 Bf5 11. O-O *

[diag]rn2k1r1/ppp1pp1p/3p2p1/5bn1/P7/2N2B2/1PPPPP2/2BNK1RR w Kgkq - 4 11[/diag]
X-FEN: rn2k1r1/ppp1pp1p/3p2p1/5bn1/P7/2N2B2/1PPPPP2/2BNK1RR w Kgkq - 4 11

Regards, Reinhard.