585
edits
Changes
UCI
,→Contra
==Contra==
* GUIs may send very long commands (for chess positions) to chess engines
* It is hard for chess engines to process input/output without an extra thread for that duty
* Missing some useful commands/info: inform chess engines the results, no information about after movestogo GUIs will reset clock or not
Excerpt concerning UCI from a [[Robert Hyatt]] interview by [[Frank Quisinsky]] in 2002 <ref>[http://www.top-5000.nl/int/crafty.htm Interview with Robert Hyatt] by [[Frank Quisinsky]], May 11, 2002, hosted by [[Ed Schroder|Ed Schröder]]</ref> :
I simply don't like UCI. It subsumes '''all''' engine control parameters. It tells the engine when to [[Pondering|ponder]], when to [[Search|search]], when to stop, etc. That is contrary to my design and I have no interest in hacking [[Crafty]] to support something that is so different from the [[Chess Engine Communication Protocol|WinBoard/XBoard]] protocol that has been around for a '''long''' time and which works '''perfectly'''.
It removes several critical engine-decisions that are best made by the engine, not the GUI. [[H.G.Muller]] wrote on a [[Talkchess]] thread <ref>[http://www.talkchess.com/forum3/viewtopic.php?f=7&t=72019&start=36] IMO statelessness w.r.t. the game state (including clocks) in UCI was a very bad idea. It is not only that it makes the communication unnecessarily verbose, but w.r.t. clocks there is a real problem: in classical TC the timing info accompanying the 'go' command does not specify how much time will be added after the 'movestogo' have been played. With movestogo=1 and wtime/btime=59000 you could be in a 40moves/hour game, at the brink of receiving another hour for the next 40 moves, in which case it would be wise to completely spend the remaining 59 sec on the upcoming move, as this is already below average. But you could also be in a 40moves/min game, where you got out of book after 39 moves, and receive only 1 new minute for the next 40. Wasting the 59 sec on a single move now effectively reduces your time for the second session by a factor 2, which would be very sub-optimal. The time management in this case should act like you have 1:59 for 41 moves (but be aware of a 'cold-turkey deadline' for the upcoming move). There is no way a UCI engine could know this.
==Pro==
