Changes

Jump to: navigation, search

UCI

1,475 bytes added, 10:11, 4 March 2020
Pro
==Pro==
* Statelessness. That reduces unsynchronised problems between chess GUIs and engines
* Easy to start a match from the middle of a game (using various opening types)
* Easy to pick up a position from long logs (for debugging purpose)
 
[[Fabien Letouzey]] emphasize the ease of implementation in a [[Frank Quisinsky|Quisinsky]] interview, April 05, 2005 <ref>[http://www.playwitharena.com/?Newsticker:Archive_7 The alternative to Crafty, Interview with Fabien Letouzey] by [[Frank Quisinsky]], [[Arena|Arena Chess GUI 3.0]] - Archive , Page 7, 96, April 05, 2005</ref> :
The choice of UCI is based on software-design principles that are not easy to explain. It's a programmer's thing really, I don't expect engine users to understand. Let me give you a clue though: think about young WinBoard engines that you have tried; how many handled pondering ... without bugs??? Another clue might be that surely, [[Stefan Meyer-Kahlen]] knows a lot about good programming, right? So trust him if not me, UCI is good for programmers because it leads to fewer bugs in the code ...
Fabien wrote a protocol translation program, [[PolyGlot]] to allow use of the new protocol on [[Linux]], though this is now supported natively by the powerful [[Scid vs. PC]] toolkit. Scid vs. PC itself includes Polyglot code to enable support for Polyglot opening books.
 
[[Pham Hong Nguyen|Nguyen Pham]] wrote on a [[Talkchess]] thread <ref>[http://www.talkchess.com/forum3/viewtopic.php?f=7&t=72019&start=36 Re: PGN standard, its improvement and standardization] by [[Pham Hong Nguyen|Nguyen Pham]], [[CCC]], October 14, 2019 » from [[Portable Game Notation]] to [[Protocols]]</ref>
 
UCI's statelessness is surely not a bad idea. Your example did not prove that (it is a bad idea) but just point out a flawed detail on UCI design.
 
A stateless protocol means a chess GUI must provide enough information each time an engine starts thinking. In your example, it cannot send enough information about the timer since the protocol does not mention it. It is not a big deal since programmers can solve that issue easily by adding some assumes. Of course, it is better one day we can fix those flawed details in the protocol (version 2?).
 
I have written engines with both protocols (UCI, WB) and now support them all in my own chess GUI. Thus I have my own ideas about the strong points of each. Both are so good and can do so well their jobs. The stateless idea is the central point of UCI, which makes it a bit more suitable for modern computers and programming - that is why recently it becomes very popular.
=Engines=

Navigation menu