UCI Protocol

[hgm]

It is not really a change in semantics. The first time the engine receives the 'uci' command it must also report its current settings.

To get confirmation that an engine obeys the hash setting you give it, it would be better to look in the task manager anyway. Even if the engine would print that it has seen the new setting, it does not mean that it obeyed it correctly. Most UCI engines cheat in this respect anyway (using memory for Pawn Hash, bitbases etc. outside the specified hash setting).

[mcostalba]

It is not really a change in semantics. The first time the engine receives the 'uci' command it must also report its current settings.

Of course it is, the UCI protocol clearly states that engine should send default value with the option:

Code: Select all

* default 
		the default value of this parameter is x

But your reply is interesting becuase very well highlights how here in talkchess, but also in many other contexts, the most debated and long discussions always arise form an incorrect statement that at first glance seems reasonable to untrained eyes.

This specific property: wrong but can trick the naive, applyes to a lot of statemnet that I have read here in the forum along the years, at the beginning I was quite negative on them, assuming people should think before to talk, but now I have changed my mind and I understand these are the sparks, the fuel that foster the long discussions: if everybody would be correct and precise in his replies probably the threads would last much less and be much shorter and eventually less "fun".

So now I understand this kind of wrong statements are instrumental to keep the forum alive.

[hgm]

'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.

[BBauer]

So now I understand this kind of wrong statements are instrumental to keep the forum alive.

This forum and other fora are for the majority.
Nothing for people used to logic argumentation.
Nothing for mathematicians.
Nothing for people who can read.

Nothing for you.

Kind regards
Bernhard

[abulmo]

'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.

Merriam-Webster dictionary:

Code: Select all

default: a selection automatically used by a computer program in the absence of a choice made by the user.

From this "official" definition, a current value that has been set by a user cannot be understood as a default value.

[hgm]

Oh, I would think it describes just that. The current value is the value that will be used by the computer in absence of a choice by the user, in UCI engines. UCI engines do not switch back to the hard-coded initial value, for every new game. After you changed it, it is supposed to stick, and thus effectively becomes the new default for all future games in the session. Some engines might even save the modified setting in an ini file, so that it becomes the new default forever.

[Daniel Mehrmann]

Most UCI engines cheat in this respect anyway (using memory for Pawn Hash, bitbases etc. outside the specified hash setting).

These cases are no UCI related topics. This happen under other protocols, like winboard, as well.

[Daniel Mehrmann]

Take stockfish for example, i do a "setoption name Hash value 1024". I then query "uci". It responds with default values. There is no confirmation nor response to my input at all. Is this inherent only to stockfish?

Well, at this point you need to trust the engine anyway. No protocol will help you if the engine starts to "lie" or doesn't do what you want.

[mcostalba]

'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"?

According to your argumentation only one would suffice.

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]

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.

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.)