UCI options case insensitive ?

[mcostalba]

I was reading UCI specifications here

http://download.shredderchess.com/div/uci.zip

and I found these lines:

Code: Select all

* setoption name <id> [value <x>]
	this is sent to the engine when the user wants to change the internal parameters
	of the engine. For the "button" type no value is needed.
	One string will be sent for each parameter and this will only be sent when the engine is waiting.
	The name and value of the option in <id> should not be case sensitive and can inlude spaces.
	The substrings "value" and "name" should be avoided in <id> and <x> to allow unambiguous parsing,
	for example do not use <name> = "draw value".

Specification says UCI options "should not be case sensitive" and this clearly breaks Stockfish (and any other C / C++ engine if this case is not properly handled) because native string comparison on those languages is case sensitive.

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

[ilari]

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

My guess is that not many. I would also guess that not all GUIs (eg. Cute Chess) implement this case-insensitivity, because it's a totally brain-damaged feature in the UCI specs. Another example of horrible protocol design is allowing whitespace inside names and values without quotes around them. That leads to interesting bugs, and makes "info" lines really slow for the GUI to parse.

[Don]

I was reading UCI specifications here

http://download.shredderchess.com/div/uci.zip

and I found these lines:

Code: Select all

* setoption name <id> [value <x>]
	this is sent to the engine when the user wants to change the internal parameters
	of the engine. For the "button" type no value is needed.
	One string will be sent for each parameter and this will only be sent when the engine is waiting.
	The name and value of the option in <id> should not be case sensitive and can inlude spaces.
	The substrings "value" and "name" should be avoided in <id> and <x> to allow unambiguous parsing,
	for example do not use <name> = "draw value".

Specification says UCI options "should not be case sensitive" and this clearly breaks Stockfish (and any other C / C++ engine if this case is not properly handled) because native string comparison on those languages is case sensitive.

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

I cannot believe you posted this, I just now made a comment in a different thread about this and had not seen this post! I noticed this a long time ago and in fact I have mis-configured many tests with Stockfish because of this.

This is really easy to fix, I assume you know that. Komodo handles this properly and always has. I'm sure if you look hard enough Komodo violates the standard somewhere else, but not to my knowledge.

I agree with you that this is a "bug" in the specification. I don't like it at all, but I believe in respecting standards.

Please fix this in the next Stockfish.

[Houdini]

In my opinion the specification makes sense, it would be silly to allow "setoption name Hash value 128" and not "setoption name hash value 128".
Houdini follows the specification and is not case sensitive for UCI options.

[Don]

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

My guess is that not many. I would also guess that not all GUIs (eg. Cute Chess) implement this case-insensitivity, because it's a totally brain-damaged feature in the UCI specs. Another example of horrible protocol design is allowing whitespace inside names and values without quotes around them. That leads to interesting bugs, and makes "info" lines really slow for the GUI to parse.

It's not what we are used to seeing, but it's a complete correct specification because the delimiters are the tokens "option", "name" and "value" so it's fully specified. What IS broken is there is no mention of whitespace at the beginning or end of tokens. The standard should state that the tokens be trimmed of whitespace at the start and end. I hate that many spaces could be inside of tokens but that is not an issue for graphical user interfaces. I sometimes use UCI manually and it can be awkward because of the whitespace issue.

Here is something that really annoys me. Look at robbolitto:

Code: Select all

RobboLito VERSION 0.084
compiled with PREFETCH
uci
id name RobboLito version 0.084
id author Yakov Petrovich Golyadkin, Igor Igorovoich Igoronov, Roberto Pescatore
id copyright Yakov Petrovich Golyadkin (all), 92th year from Revolution, PUBLICDOMAIN (workers)
id dedication To Vladimir Ilyich
option name TranspositionalTabularSizing (Zobrist) in MegaBytes. Note: Only dyadic powers suffice terminally! type spin min 1 max 16384 default 32
uciok

I have a super fast autotester which is configured manually. To set the Hash table size for robbo I have to do this:

Code: Select all

TranspositionalTabularSizing (Zobrist) in MegaBytes. Note: Only dyadic powers suffice terminally! = 64

In my view it would have been better for UCI to have 3 tokens, one as a description for display only, one with no white space allowed to represent the internal name of the token and then the value. OR perhaps the description is to be used only as an ADDITIONAL element for GUI's, something that can be used for help or for any purpose the GUI designer wants or is ignored. It could be one of those boxes that come to life when you drag the mouse over it.

[ilari]

It's not what we are used to seeing, but it's a complete correct specification because the delimiters are the tokens "option", "name" and "value" so it's fully specified. What IS broken is there is no mention of whitespace at the beginning or end of tokens. The standard should state that the tokens be trimmed of whitespace at the start and end. I hate that many spaces could be inside of tokens but that is not an issue for graphical user interfaces. I sometimes use UCI manually and it can be awkward because of the whitespace issue.

I agree that the specification is complete. But it's still very annoying and inefficient from a GUI developer's perspective. If quotes were required around strings that contain whitespace, parsing "info" and "option" lines would be a lot easier and faster. Now the GUI has to compare every whitespace-delimited token (eg. every move in a principal variation) to each of the keywords, which in the case of "info", are many.

In my view it would have been better for UCI to have 3 tokens, one as a description for display only, one with no white space allowed to represent the internal name of the token and then the value. OR perhaps the description is to be used only as an ADDITIONAL element for GUI's, something that can be used for help or for any purpose the GUI designer wants or is ignored. It could be one of those boxes that come to life when you drag the mouse over it.

Yes, it would be SO much better if there was a separate token for the description. I guess UCI was designed to be easy to read by humans, despite the fact that it's meant to be used for communication between a GUI and an engine. UCI is the COBOL of chess engine communication protocols.

[ilari]

In my opinion the specification makes sense, it would be silly to allow "setoption name Hash value 128" and not "setoption name hash value 128".
Houdini follows the specification and is not case sensitive for UCI options.

Case-insensitivity would make sense if the engines were meant to be operated directly by humans. But for communication with another process it just complicates things.

[Gian-Carlo Pascutto]

Specification says UCI options "should not be case sensitive" and this clearly breaks Stockfish

UCI is the standard, so it can't break anything. You mean that Stockfish is buggy.

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

Deep Sjeng has always done this correctly as far as I know.

Case-insensitivity would make sense if the engines were meant to be operated directly by humans.

I often operate the engine manually with UCI, for example to quickly analyze some position on a remote system. This is much easier if whitespace and case sensitivity are handled as the specification requires.

[Don]

In my opinion the specification makes sense, it would be silly to allow "setoption name Hash value 128" and not "setoption name hash value 128".
Houdini follows the specification and is not case sensitive for UCI options.

That is a surprise - to me it's silly to see them as the same thing - they are clearly 2 different things to me. Do you see 'h' and 'H' as the same character? I see them as distinctly different and it's illogical to map them differently.

The argument is that humans see them as the same, but that is inconsistent and wrong too. Is your name "robert" or is it "Robert"? I think you would be offended if everyone else was capitalized but you were not.

This is likely to be a Unix mentality vs Windows mentality things. Unix is considerably more regular and consistent about handling things like this as well as providing much cleaner abstractions for most things and adhering to the KISS principle when there is no reason to do otherwise. As witness to this, notice that programmers made the mistake of dong the logical thing which violated the illogical specification in this regard.

Generally, if you have to go out of your way to honor a specification there needs to be a logical reason why that is so. In this case you have to go out of your way to implement something that is NOT logical. Not just us developers but the computer has to do more work too for no good reason.

However, I still think UCI is very well done. It is not possible to make a specification that will please everyone in every way.

[Don]

Specification says UCI options "should not be case sensitive" and this clearly breaks Stockfish

UCI is the standard, so it can't break anything. You mean that Stockfish is buggy.

That is what I meant to say. Stockfish is broken, not UCI.

So I was wondering how many of you, engine programmers, has added the proper workaround code to correctly handle the specification ?

Deep Sjeng has always done this correctly as far as I know.

Case-insensitivity would make sense if the engines were meant to be operated directly by humans.

I often operate the engine manually with UCI, for example to quickly analyze some position on a remote system. This is much easier if whitespace and case sensitivity are handled as the specification requires.

This is my argument too. I personally believe that UCI should have been case sensitive but I respect that this is matter of viewpoint. But it's really awkward when you get used to thinking it isn't, and then find that it IS for some programs and then you are constantly working around things.

It's strange that in order to make everything work you have to ASSUME that it IS case sensitive.