Engine authors, beware of false-draw-claim forfeits!

[mhull]

Won't happen unless you adopt something contrary to FIDE rules. Then I won't care because I am not going to support crappy standards (such as UCI) that differ from the rules I have to use in real tournaments... Current crafty handles draw offers, accepting draws, draw claims, perfectly. I don't see that changing

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

It's a wrong standard because it takes away some chess-playing decisions from the chess program and gives it to the GUI. Then you end up with chess tournaments that are essentially running "clone" chess decision components (e.g. GUI). It encourages the relegation of the chess program to just a game-tree searcher. From a design standpoint, it's both bad and wrong.

[Zach Wegner]

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

I hate the UCI protocol. I am actually almost done implementing it, but that is for proof-of-concept and portability reasons only. Here are some reasons:

1. Its semi-stateless-ness: It at once makes it impossible for the engine to know the whole game, while still making it keep track of the current position. This would be best if it went totally stateless and added the position to the "go" command.
2. The lack of control, mentioned above, in things like draw offers and resignation.
3. The pondering issue.
4. It's ugly. This is to be expected because it's an "English" protocol written by non-native English speakers. It makes me cringe to read "currmove" and "readyok" in my own code.

Some other little things that bother me:
-It does not define a FEN but still uses them.
-It defines Shredder bases, when obviously only one engine uses them.
-Its incompatibility with other protocols in engine design. The xboard protocol and my console mode protocol are very similar, and require minimal changes in the main flow of the program. But when implementing UCI I have to litter the code with "if (protocol == UCI)". Based on this I am considering to remove support at some point.

I think it is popular because it is easy to implement and practically "universal". It does have some advantages, such as the standard exchange of search data and parameters. But I think the "perfect" protocol is somewhere in between XBoard and UCI.

[Matthias Gemuh]

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

BTW, UCI version of Crafty plays fine.
Its name is Patriot 2006.

Matthias.

[swami]

Zach, Thanks for an explanation
I knew nothing about it, atleast I did learn something about this stuff, I thought that both of these protocols are same and that UCI has slight edge over the winboard until Bob started talking about it...

[swami]

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

BTW, UCI version of Crafty plays fine.
Its name is Patriot 2006.

Matthias.

was it complete Crafty?I dont think so, It was around for a long time until later it was proved to be a clone, Elchinito was an UCI engine and a crafty clone too...

[Alessandro Scotti]

I hate the UCI protocol. I am actually almost done implementing it, but that is for proof-of-concept and portability reasons only. Here are some reasons:

1. Its semi-stateless-ness: It at once makes it impossible for the engine to know the whole game, while still making it keep track of the current position. This would be best if it went totally stateless and added the position to the "go" command.
2. The lack of control, mentioned above, in things like draw offers and resignation.
3. The pondering issue.
4. It's ugly. This is to be expected because it's an "English" protocol written by non-native English speakers. It makes me cringe to read "currmove" and "readyok" in my own code.

Some other little things that bother me:
-It does not define a FEN but still uses them.
-It defines Shredder bases, when obviously only one engine uses them.
-Its incompatibility with other protocols in engine design. The xboard protocol and my console mode protocol are very similar, and require minimal changes in the main flow of the program. But when implementing UCI I have to litter the code with "if (protocol == UCI)". Based on this I am considering to remove support at some point.

Well then let me add why I love UCI!

1. It's stateless (I don't keep state anywhere in Hamsters)
2. It helps authors from entering endless discussions re: how to handle draws
3. Pondering is no different than the standard search: no bugs
4. My standards are not so high, so no comment on this!

Re: protocol incompatibility that's very true though certainly not a "fault" in UCI. I think that any program that wishes to support both Winboard and UCI should be designed carefully. I also think that it would be much easier to add Winboard to an UCI engine than the other way around.

In no part of the code Hamsters knows that it's using the UCI protocol by the way, the engine is given an I/O adapter as a parameter to the search:

Code: Select all

struct SearchAdapter
{
    virtual int get_event() = 0;
    virtual int send_newsearch( unsigned time ) = 0;
    virtual int send_info( unsigned time, int depth, int seldepth, int score, Uint64 nodes, int hashfull ) = 0;
    virtual int send_currmove( const Position & pos, unsigned time, Move move, int move_number ) = 0;
    virtual int send_bestmove( const Position & pos, Move best_move, Move ponder_move ) = 0;
    virtual int send_pv( const Position & pos, unsigned time, int depth, int seldepth, int score, Uint64 nodes, const Move * pv, int multipv = 0 ) = 0;
};

Options are also abstracted and handled in a similar way.

[Matthias Gemuh]

Well then let me add why I love UCI!

1. It's stateless (I don't keep state anywhere in Hamsters)
2. It helps authors from entering endless discussions re: how to handle draws
3. Pondering is no different than the standard search: no bugs
4. My standards are not so high, so no comment on this!

Re: protocol incompatibility that's very true though certainly not a "fault" in UCI. I think that any program that wishes to support both Winboard and UCI should be designed carefully. I also think that it would be much easier to add Winboard to an UCI engine than the other way around.

In no part of the code Hamsters knows that it's using the UCI protocol by the way, the engine is given an I/O adapter as a parameter to the search:

UCI is the prefered protocol in commercial engines because it is far better than WB. WB may make sense to some programmer but the user is left in darkness because GUI has no idea what engine is doing and so cannot inform user.

Someone complained about "currmove" in UCI as if "force" makes better sense in WB.


Matthias.

[Pradu]

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

There are still many programs that support, and will continue to support the WB protocol. The main reason I chose the WB protocol is because Winboard/Xboard is one of the most versatile chess engine interfaces especially for chess engine testing on machine vs machine or on an ICS and it works on many platforms. In reality I guess it doesn't matter what protocol you choose because there are protocol converters like WB2UCI or polyglot.

[bob]

Won't happen unless you adopt something contrary to FIDE rules. Then I won't care because I am not going to support crappy standards (such as UCI) that differ from the rules I have to use in real tournaments... Current crafty handles draw offers, accepting draws, draw claims, perfectly. I don't see that changing

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.

How do you handle offering/claiming draws? Why does the GUI need to tell my program when to ponder, what to ponder, when to search, etc, when Crafty already has code to do all of that. New, or not, it is a kludge, as the GUI is usurping responsibilities that normally lie within the engine. The GUI is responsible for serving as a "User Interface" which is the UI part of GUI. It should not deal with tablebase probing, what/when to ponder, etc...

that is why I don't like it and why I don't support it. It is completely different from the xboard-type interface many of us have used for years...

[bob]

This brings up an interesting question regarding the "insufficeint losing chances rule".

In the absence of a digital clock, when in a sudden death time control, a player can summon a T.D. and request a draw due to insufficient losing chances.

Is there a programming equivalent that must be adhered to if tablebases are present at the side "down" in material is in a drawn tablebase position?

I think a program down a pawn in a 5-piece draw should be able to declare the draw and not have to lose on time.

I do not believe this factors in to FIDE rules at all. The rule is that if you are playing (say) KRR vs KN, and your flag falls before you force the mate with the KRR, you still can not lose since your opponent lacks the material to force a mate. If you have a single pawn, this can never apply since it can always promote to a queen or rook.

FIDE used to factor in tablebase results for drawing decisions, such as extending some endings where a win can be demonstrated, but it takes more than 50 non-reversible moves to do so. Those exceptions were later removed from the rules, reverting to the pre-tablebase 50-move-rule with no exceptions era...