UCI Protocol

[mcostalba]

You place the way you or someone else happened to implement UCI above the official specs? How remarkable! I would have expected it is pretty obvious that implementations count for zilch. Especially if they are poor or silly implementations.

Nice

Today we learn that _all_ UCI engines to date have a poor and silly implemantation of uci options.

Usually a default value is simply the value to which the actual value is initialized. There hardly ever is a reason to remember that initial value separately. UCI is certainly no exception to that: the default values are never needed after a setoption would have changed them. Doing so would just be a waste of memory / programming effort. This is not something that is dependent in any way on what 'default' exactly means, it is a hard fact.

In UCI one cannot implement 'reset' buttons that would reset all option values to their defaults, because the GUI cannot be aware of the side effects of such an option on other options, and would get totally confused. WB protocol is superior in this respect: there the engine can declare options that display as 'button' as type 'reset' or 'save', to make the GUI aware that exercising the option has side effects, and either invalidates the GUI's list of engine options, or requires a prior full update of all other option settings, respectively. For WB implementations that include a 'reset' button it could make sense to separately remember default values, or at least values to which you want to reset the options covered by the button. (Of course you could make an entire 'menu' of buttons to set a large group of options to different combintations of settings.)

Remarkable! You should do the lawyer.

[hgm]

Today we learn that _all_ UCI engines to date have a poor and silly implemantation of uci options.

Not surprising, of course, if you realize they are mostly clones of each other!

But this is not a matter of debate. There are objective standards. And these say it is poor design to hang on to data that you will never need again.

Whether 1, 10, or even a million people do it does not have the slightest effect on whether it is silly or not. They would still waste memory space on data that is never needed again, just a million times more in total... This is why we are taught already in kindergarten that "but he does it too" is not an acceptable excuse.

[Rein Halbersma]

Today we learn that _all_ UCI engines to date have a poor and silly implemantation of uci options.

Not surprising, of course, if you realize they are mostly clones of each other!

But this is not a matter of debate. There are objective standards. And these say it is poor design to hang on to data that you will never need again.

Whether 1, 10, or even a million people do it does not have the slightest effect on whether it is silly or not. They would still waste memory space on data that is never needed again, just a million times more in total... This is why we are taught already in kindergarten that "but he does it too" is not an acceptable excuse.

What extra memory? The few dozens strings that correspond to the default values? Surely that is not going to affect engine performance?

[michiguel]

'default' in English means "what will be used in absence of further specification". The currently set value obviously satisfies that description better than some hard-coded value that has already been overruled.

Are you aware that in all UCI option struct implementation you have 2 fields: "default value" and "current value"?

Not necessarily all. Gaviota shows whatever value will keep if nothing is altered (that is the current value, which is the same as the default the first time uci is sent).

According to your argumentation only one would suffice.

To be compliant with UCI, only one is sufficient.

This discussion centers around a moot point, because the "uci" command is supposed to be sent once and only once. Because of that, if it is sent twice it is not an expected behavior from the GUI, so "uci" should be treated as an unknown command. Therefore, it should be ignored if we are pedantic with the UCI protocol. That would be the proper behavior. Then, only one parameter is needed.

Regardless, this discussion seems to be about a hypothetical protocol that sends "uci" twice, and what would be more "logical" to report. In that respect, the current value (which becomes the new default) makes sense, since it is the one that will remain if the GUI does not change it before sending "isready" again. Showing the original default is misleading for the GUI if it sees the value, does not change it, and then what remains is something else. In a hypothetical protocol, the engine should show what value will remain in effect if the "user" does not change anything. Or, the protocol should spell it out it the original default is expected.

But again, none of this is contemplated by UCI.

Miguel
PS: This behavior regarding the uci command is something clumsy about UCI, IMHO. Pedantically, it forces the engine to remember how many times uci was sent. But, I bet none do, out of laziness (Gaviota included).

Of course I am not really interesting to argue on this because we both clearly understand you are wrong, but I am just probing your indeed remarkable skill of "climbing on a glass window"...yes, I am having a bit of fun too

[hgm]

What extra memory? The few dozens strings that correspond to the default values? Surely that is not going to affect engine performance?

I did not say it affected performance; just that it was silly. You can do many silly things without affecting performance. But that does not make them any less silly. There are many worthy goals other than performance. Like code readability, avoiding compiler warnings, not wasting typing effort...

[Daniel Mehrmann]

In UCI one cannot implement 'reset' buttons that would reset all option values to their defaults, because the GUI cannot be aware of the side effects of such an option on other options, and would get totally confused.

I don't see any problems here. The engine doesn't offer a "reset" button. It's simply not necessary. This will be done by the GUI. The GUI can send all options with the defined default value and that's it. (BTW Arena does it on that way mostly)

There are no unkown "side effects", because the engine starts with these settings. If that would be true, it's a task for the programmer to fix it.

[Daniel Mehrmann]

PS: This behavior regarding the uci command is something clumsy about UCI, IMHO. Pedantically, it forces the engine to remember how many times uci was sent. But, I bet none do, out of laziness (Gaviota included).

You hit me!