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

[Sven]

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.

Please take into account the history of xboard/WinBoard which can be read here, for instance. Initially xboard was a (UNIX) user interface written only for GNU Chess, and this was long before PGN standard and FEN had been defined in 1994. The communication between xboard GUI and GNU Chess was done via a protocol that was close to what is called "WinBoard protocol v1" today. So "setboard" using the FEN standard could not exist at that time. There were good reasons not to throw away the whole protocol later on, but instead to define the improved WB protocol version 2 where adding the "setboard" command was one of several important changes.

Therefore I think it is not appropriate to call the xboard protocol "wrong from the start" and base this on the argument that v1 was not using FEN yet. It simply couldn't, like the people in Stone Age had no television yet and therefore couldn't watch football games.

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.

There are for sure different opinions about which kind of protocol is "better": the "stateless" UCI or the "stateful" WB. It is o.k. for me if the stateless approach is your favourite. My preferences are different but I do not try to convince you. I think this is the best way to handle different views when it seems impossible to objectively decide which one is "better". At least one thing is obvious, though: for both WB and UCI protocols there are a lot of engines implementing it without any serious problems.

Sven

[hgm]

What do you think about it?

The only satisfactory solution I could think of is to set up a predecessor position, and then make moves from it to create the desired position, but without castling rights, because the moves destroy them.

For e.p. rights this is easy: just take back the Pawn double-push, and set up that position. For positions without castling rights, it can be arbitrarily complicated, because the Rook can be trapped without moves. I don't consider it worth the effort. If users really want to play v1 engines with corner Rooks without castling rights, let them devise the required loading sequence themselves, and load the alternative position plus the required moves from a PGN file, rather than a FEN. (E.g. 1. Nf3 Nf6 2.Rg1 Ng8 4.Rh1 Nf6 5.Ng1 Ng8 to destroy the K right in the opening position.)

I don't think allowing the v1 engine to castle is a solution. A v2 opponent would refuse the castling unless you adapt the castling rights for that one too, and in that case you would not be doing what the user asked. When I play the opening position with KQ rights in stead of KQkq, I will have a reason for it. (E.g. testing how many Pawns the castling rights are worth.) Having the GUI 'correct' the rights would totally subvert that goal.

[Sven]

What do you think about it?

The only satisfactory solution I could think of is to set up a predecessor position, and then make moves from it to create the desired position, but without castling rights, because the moves destroy them.

For e.p. rights this is easy: just take back the Pawn double-push, and set up that position. For positions without castling rights, it can be arbitrarily complicated, because the Rook can be trapped without moves. I don't consider it worth the effort. If users really want to play v1 engines with corner Rooks without castling rights, let them devise the required loading sequence themselves, and load the alternative position plus the required moves from a PGN file, rather than a FEN. (E.g. 1. Nf3 Nf6 2.Rg1 Ng8 4.Rh1 Nf6 5.Ng1 Ng8 to destroy the K right in the opening position.)

I don't think allowing the v1 engine to castle is a solution. A v2 opponent would refuse the castling unless you adapt the castling rights for that one too, and in that case you would not be doing what the user asked. When I play the opening position with KQ rights in stead of KQkq, I will have a reason for it. (E.g. testing how many Pawns the castling rights are worth.) Having the GUI 'correct' the rights would totally subvert that goal.

I meant (and wrote) that the internal board of WinBoard/xboard should be changed, not just the "edit" sequence sent to the v1 engine. Of course you cannot send two different positions to the two engines.

There are not many alternatives:

1. Change the position for both v1+v2 engines based on the "v1" assumption, as I proposed. Not what the user wants but consistent and fair.

2. Punish the v1 engine for something it is not responsible for, which is the current way. Not what the user wants, and not really fair.

3. Completely refuse to play the requested position. Not what the user wants, but somehow "consistent".

4. Do something that sounds really weird, like trying to invent a "previous move" as you mentioned, to set up the required position that lacks some castle rights. If done successfully, this results in getting what the user wants. I did not have that in mind initially but indeed it is something to think about, at least.

Obviously no. 4 seems to be "optimal" for the user. But it is still possible that the attempt to find a previous move fails for some reason, so the existence of a solution is not 100% guaranteed. But it would be better than nothing.

I could accept, though, if you say it would not be worth the effort to implement no. 4, which is not really "neglible" since some kind of retro-analysis is involved. In that case I would stil vote for either no. 1 (my proposal) or no. 3. Both have nearly the same effort for implementation because both need to detect that there is at least one v1 engine present and there is a mismatch between actual castling rights and "assumed" castling rights. For no. 3 an error would be thrown while for no. 1 the internal board would be changed (silently or accompanied by some message).

I think that the current solution, no. 2, is worst of all.

Sven

[hgm]

Well, fairness between engines is lower on my list as doing what the user wants. Furthermore, it is a bit of a subjective criterion.

I would prefer a weakened form of (3): warn the user that the engine is v1, and might play an illegal castling when playing from this position.

I agree that solotion (2) is bad. It did have one thing strongly in favor of it, though: it took zero effort to implement it, as this was how things came out to be after paying attention to the castling-rights field of a FEN. In practice this seems to be a non-problem; no one ever complained about it. Apparently the heuristic employed by the engine to assign castling rights works pretty well in practice. I ran into it, but only doing things that are very a-typical: When determining the value of Nightriders, I self- played Fairy-Max with one side having Nightriders in stead of Rooks. As Fairy-Max at that time did only allow castling with Rooks, the Nightrider side could not castle, and this seemed an unfair disadvantage not related to the intrinsic piece value of Rook vs. Nightrider. So I started with FENs where neither side had castling rights, and then it turned out that the side playing the Rooks ignored this, and prduced illegal castling moves.

[Sven]

I would prefer a weakened form of (3): warn the user that the engine is v1, and might play an illegal castling when playing from this position.

"... even though conforming to protocol v1."

Yes, maybe this is a good compromise at least. Thanks for considering it.

Sven