cnchang wrote:There should be a more updated UCI protocol standard, newer than this 2004 edition, which includes the consideration of SMP. Is the person chartered UCI still operating?
This is the latest version I am aware of. UCI is sort of 'carved in stone'; I consider it a 'dead protocol' in the same way as Latin is a dead language. The person that invented it is Stephan Mayer-Kahlen, the author of the commercial Chess engine Shredder. He is still active, but he sees no need to make any modifications. In his opinion there is no need for any protocol extensions, as he considers the announcing of options by the engine a general extension mechanism. Most customers don't play engines against each other, but use them for analysis of their own games. With only a single active engine, it becomes kind of immaterial whether you control options as a common or an individual option. I once explained him it would be very useful to have a standard option for maxthreads, but he was apparently not convinced.
If UCI is an open standard, there should be no secret options allowed in public, at least, not on such an important one. Secret ones or no standard at all are both unacceptable. Winboard just randomly picked some name for threads# out of the thin air?? Are you kidding me?
You should realize that WB protocol was developed in a time where 256KB was huge amount of memory, and even hash tables a technical impossibility except on the World's largest super-computers. So originally commands to control hash size and threads were not part of the protocol. When I took up work on WB this is one of the first things I corrected. After some brain-storming with other engine authors I picked the commands 'memory' and 'cores' for this. Unlike UCI, WB protocol is a living protocol, which is constantly evolving to satisfy the needs of engine programmers.
Regarding the possible use of different hash settings for each engine, I just tested something related to that. I wonder how Shiga 64MB/1core stacks up against 512MB/4cores. When I set both to run with time control 40 steps/10minutes. They drawed. But, with the time control 10 steps/10 minutes, Shiga 512/4 won. This kind of test can only be done with the help of Shiga.ini now because of Winboard's decision. UCI doesn't list hash size as "not need to appear in this dialog" may find a cause here.
Indeed, but this is a GUI-design issue, not a protocol matter. Some people want to play 'core-odds' games, where engine versions with different threads are pitted against each other. They are unhappy with this design. But WB has work-around options that can be used to subvert the ordinary design, albeit not through the GUI. There are command-line options -first/secondInitString, which control the command(s) send at the beginning of every game to the engine. Normally this is just the 'new' command, but people that want to do core odds could set it to 'cores N\nnew' to precede the 'new' command with the desired cores setting, overruling a possible earlier 'cores' command corresonding to the Common Engine settings. So I don't consider it a big problem. My philosophy for WB development is that normal things (like fair games) should work simple and intuitive, while advanced special applications can be a bit more 'hidden', so they don't confuse normal and beginning users.
"Ponder" must be a common engine option for any meaningful game. Thus, it should be centrally controlled. Isn't it?
Indeed. And in WB it is (from the General Options dialog). Note, however, that not all engines can ponder, and that the support of the Ponder option by the engine should be taken as a signal to the GUI that it can. And that 'Ponder' is not the option that controls whether UCI engines ponder or not. To set the engine pondering there are other commands "go ponder ..." (so not any ' setoption'), and the GUI has to set up the position on which the engine must ponder first. Commands the GUI never should use for an engine that does not support a 'Ponder' option. So much more is at stake than just a 'setoption name Ponder' command which you might be able to send blindly without adverse effects. The 'Ponder' option is a time management option, which would be more properly described by 'TakeMoreTimeThanYouCanAffordForEachMove' (anticipating on that you will gain extra time through ponder hits).
Above all, I can't see the reasoning behind this:UCI wrote:...
It sets the "confess all your options first at startup before putting em into use" rigid rule on the engines while setting a relatively lax rule on the GUI side, "need not to send setoptions if GUI doesn't feel like it", without elaboration. How arbitrary and strange!
Well, all protocols need arbitrary decisions in their design. This is where there can exist more than one protocol for the same task. Important is that there is handshaking, and any handshaking could be initiated from either side. UCI has arbitrarily chosen to let the engine start it. In WB protocol we also did this, for backward-compatibility reasons (which were of no concern when UCI was designed). Engines announce which protocol extensions they support, and the GUI will refrain from using protocol that could confuse older engines and break their operation. This because even the handshaking capability was only added later. So an attempt of the GUI to initiate the handshaking would already look a non-compliancy to very old (so called WB v1) engines, and confuse them. So the engines must start the handshaking to let the GUI know they support, and if they don't, the GUI assumes they are v1 after a timeout.
UCI seems based on a philosophy that standard options should be disguised as engine-specific options, thus minimizing the number of dedicated commands in the protocol. For engine-specific options it is obvious that the engine has to announce them, or the GUI could never know they existed. Which options should be controllable from which dialog (or indeed, should be controllable at all by the user) is a matter of GUI design. The task of the protocol is to not restrict the GUI-designer in this respect.
But don't expect me to defend UCI; personally I think it utterly sucks, and I would rather die than have my own engines use it. Poor standardization of is options is the least of its problems. But it is what it is, and I had no say in its design. As long as there are engine authors stupid enough to use it, we are stuck with it...
