xboard don't allow start position w/o casling rights !

[Chan Rasjid]

Hello,

I have just implemented the UCI protocol for my engine. There is a bug somewhere that eludes me and xboard is not helping.

The uci position command is:
position [fen <fen_string> | startpos] moves <move1> <move2> ... <movei>

My UCI engine can play matches against other engines (only from the new game start position) without problem till end as long as the position command to my engine is :
position startpos ...
It will fail to play from setup positions from fen files when it receives the position command with "fen" :
position fen moves <move1> ...

To debug , I manually created the chess startup position file "w_startpos.fen" :
"rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w - - 0 1" - without castling rights only.
Then I setup xboard with this file expecting that the position command sent to my engine would be the "fen" format. But xboard "corrected" my fen string back to :
"rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1" which can be seen in this xboard/polyglot log output:

==========
POLYGLOT WAIT
< XBOARD setboard rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
POLYGLOT FEN rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
POLYGLOT WAIT
< XBOARD computer
< XBOARD name Crafty-23.1
=======

So _back_to_square_one_ when my engine again receive the "position startpos ..." command. So I can't trace my bug.

xboard does not allow the chess start position with the castling rights edited away!

Rasjid.

[hgm]

Which version?

[Chan Rasjid]

Which version?

From "About xboard" , it is 4.2.7

edit: I am using debian, so not winboard.

Rasjid

[hgm]

Well, 4.2.7 is not castling/ep-rights aware at all. So it will simply ignore the castling and e.p. fields of the FEN, as it has no internals to handle such info. See the section 'limitations' on the man page.

This is what you get when using stone-age versions. Use 4.4.3, or better yet, 4.20100327. (Although Debian might not have upgraded beyond 4.4.2 / 4.20100118 yet.) All 4.3 versions and later support full castling awareness (Although 4.4.1 had a bug in FEN pasting that caused regression there.)

[Chan Rasjid]

Well, 4.2.7 is not castling/ep-rights aware at all. So it will simply ignore the castling and e.p. fields of the FEN, as it has no internals to handle such info. See the section 'limitations' on the man page.

This is what you get when using stone-age versions. Use 4.4.3, or better yet, 4.20100327. (Although Debian might not have upgraded beyond 4.4.2 / 4.20100118 yet.) All 4.3 versions and later support full castling awareness (Although 4.4.1 had a bug in FEN pasting that caused regression there.)

I don't know who edited my fen string. It must be xboard which read the fen files and not polyglot. So it seems xboard did some strange parsing for fen/chess legality which seems not necessary.

Rasjid.

[hgm]

GUIs never just pass on text from user to engine or between engines. They parse it to extract the information. When a FEN string is sent to the engine, it is built from scratch, based on the internal board representation. There is as much relation between the original FEN string you pasted and the one the engine gets as there is between the paint of the Mona Lisa and the words with which you would describe it to me when recounting your visit to the Louvre. Especially if you were color-blind like XBoard 4.2.7 is 'castling blind'.

I have no idea why you bring up Polyglot. All Polyglots I know are fully castling aware, and although they work the same way as most GUIs (i.e. not passing the info, but parsing it to internal representation, and rebuilding itt from that), this means the castling rights should come out equivalently. (But it migt be AHah where it received KQkq, when the Rooks are on the a- and h-files.)

[Chan Rasjid]

I mention polyglot because my engine in UCI mode with xboard need it.

Sorry, my slip - xboard has to parse fen to show where the pieces are. From my original post (polyglot log output ), it is clear xboard passed a fen to polyglot with 'KQkq'.

Stone-age xboard assumes castling when K/R in their original positions

Thanks,
Rasjid

[hgm]

Stone-age xboard assumes castling when K/R in their original positions

Exactly. Not having any internal memory for castling rights it is the best it can do. In fact, in WB protocol v1 there is not even a way to tell otherwise to the engine, even if XBoard would know better: the 'edit' command has no way to specify castling rights, and the specs say the engine should assume it has castling rights if K and R are in the original position. Only by being v2 and supporting setboard, the engine can learn about the castling rights, now the more recent XBoard versions keep track of those. But v1 engines (such as Fairy-Max) I can still not run with the position you wanted to use. They would be forfeited for illegal moves (castlings), as XBoard now is aware that castling was not allowed, but the engine isn't.

[Sven]

Stone-age xboard assumes castling when K/R in their original positions

Exactly. Not having any internal memory for castling rights it is the best it can do. In fact, in WB protocol v1 there is not even a way to tell otherwise to the engine, even if XBoard would know better: the 'edit' command has no way to specify castling rights, and the specs say the engine should assume it has castling rights if K and R are in the original position. Only by being v2 and supporting setboard, the engine can learn about the castling rights, now the more recent XBoard versions keep track of those. But v1 engines (such as Fairy-Max) I can still not run with the position you wanted to use. They would be forfeited for illegal moves (castlings), as XBoard now is aware that castling was not allowed, but the engine isn't.

I do not quite follow your statement in the last sentence. IMO it is not the fault of a v1 engine that it makes a castling move if it has set up its internal board exactly in conformance to the WB spec. Therefore I would not consider "old-fashioned" v1 engines as being now broken. Not even the protocol has changed in the meantime w.r.t. this topic, it was only the WinBoard/xboard GUI that has changed its behaviour.

The problem does not affect special opening positions like the one above only, you can see it also in endgames like this one:
[d]
With castle right set it is a win, without it it's a tablebase draw.

Would you agree that it might be a good idea to think about a solution on GUI side for this? If at least one engine has not sent "feature setboard=1" in reply to "protover 2" and the GUI has to send a new position to all connected engines where any of the real castle rights differs from the v1 protocol assumption "K and R on original squares" then the GUI might remember this situation as a "presenceOfV1EnginesRequiresExtraordinaryCastlingPermission" flag , and change its internal board to allow castling based on the WB v1 assumption.

I know this sounds for you, and I know why. It is one of your declared goals to better get rid of special workarounds for the "devils of the past" in WinBoard/xboard than to add new ones. However, in this case I think that the introduction of castling awareness into the GUI (which was definitely a good thing and necessary) has opened this little hole and *may* be considered as not having been done 100% completely. Since the current behaviour may lead to forfeiting the v1 engine but the proposed behaviour only forces a possibly present v2 opponent to play a slightly different position than required, I can see no unjustifiable disadvantage being created for the v2 engine. Still the situation is that you can't play the original position if one v1 engine is present, but at least you *can* play.

What do you think about it?

Sven

[Chan Rasjid]

UCI has many advantages over the xboard protocol. It seems the xboard protocol is wrong from the start:-
1) 'edit' command is just bad. Setting position the fen way (as in UCI) is clean and could have been an obvious way to go.
2) uci 'position' command is smart. It takes away the need for programmers to worry about takeback a move, loading pgn games, etc. it sends the originating fen position + all game moves. The programmmer just do a 'setboard' and 'make' all the moves and it would lead to where to start searching from. The programmer don't need to know if a human player took back moves, etc. The GUI programmer add some codes and all chess programmers benefit. Interfacing with UCI is much easier for the programmer.

The only problem is the current free linux UCI GUI do not have enough features for chess program development. Only xboard is available with the polyglot adaptor.

May be someone has to make one. I am thinking if I can ...

Rasjid