UCI Implementation in Arena: Bug

[mcostalba]

Hi Marco,


Yes this was about the feature request, I also sent the bug report but on that I got no answer.

The problem is that on one hand I would like some feedback from Martin. On the other hand he would be busy answering all mails.

Michael
http://www.playwitharena.com

Thanks Michael for your answer.

I didn't check Arena sources, nor I'm willing to do. But from the discussion here around this long standing, possibly the worst bug of Arena, I have made up my mind that it is absolutly not trivial to fix, just to be clear the new feature proposed it takes about 10 minutes (testing included) to be implemented. Instead this bug could take weeks in case the whole process interface had to be rewritten and also testing of the resulting source is much more difficult and tedious.

So I can understand the developer finds something else more rewarding and easy to implement....but the point is that this single bug makes Arena GUI not usable by a large part of engine developers.

Of course we (and Arena developer) can live with that, but it is important to highlight this point.

[Damir]

Arena users included...

[WinPooh]

Just another feature request: make Arena suitable for running fast or super-fast blitz games between engines (1 min/game, with zero time increment). Currently Arena is known to cause too many games to be lost on time... while in other interfaces the same engines play super-blitz w/o problems.

And time control granularity less than 1 minute would be great too.

Please, no more new graphical bells and whistles - just two these little fixes

[Greg Strong]

Beta of Arena 2.5 released! And they implemented my request for an option to auto-rotate the board in gauntlet tournaments

Thanks for the hard work guys!
- Greg

[beachknight]

Beta of Arena 2.5 released! And they implemented my request for an option to auto-rotate the board in gauntlet tournaments

Thanks for the hard work guys!
- Greg

I am running a gauntlet (Gull 1.1) on 2.4.0 beta for the time being
and seeing the rotating board. A superb feature! Thanks.

Best,

PS: Arena team also implemented my request to include a draw adjud.
option for avoiding unnecessary long games in cases KR v KR and the
like. One can now set the number of move for the early (and timely!) draw.

[Don]

Hi Miguel.

Go ahead and adjust the issue in Gaviota. I had to do it in Telepath a couple of years ago. Arena is not the only UCI GUI with that problem.

Charles

Why not get the Arena guys (and others) to fix the GUI to match the specifications, rather than making the programs match the interpretation? You could find yourself with cases that are incompatible if the standard is not adhered to.

I agree 100% with that.

Stockfish is an offender in violating the UCI standard too. Here is the relevant section of code:

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.

In Stockfish you you must match the exact case of the option and value or Stockfish won't honor it. This is the kind of bug that could cause you to lose games if you are dealing with tools that expect the standard to be respected. It has little affect in the case of Stockfish because most tools and GUI's retain the case sent by the engine, but they are not required to do so. But if you are setting up programs with configuration files you could easily get this wrong and I have been bitten many times by this bug which is so trivial to correct.

Sometimes you are tempted to make tools more forgiving with respect to standards, but I think this encourages non-adherence and makes the problem worse because people are sometimes not even aware there is a bug.

Personally I think UCI names and values should have been case sensitive, but it doesn't matter what I think, it's not.

Several years ago I tried to parse a huge database of PGN games and I had to continue to patch my parser to deal with the fact that the games were not proper PGN with respect to the SAN notation. It didn't just happen 3 or 4 times but it went on and on, I would fix one thing and then at some point someone thought of a different way to violate the standard. It was unbelievable how many ways castling was represented in this database, practically every combination of upper and lower case 'o' and the zero character as well as the hyphen missing or included arbitrarily and let's not forget "Kg1" was in there a few times to mean O-O. Also you would see N3d2 when Nfd2 was the correct disambiguation. I could go on and on. Fortunately we have good tools that can clean up some of these issue and you rarely see this any more.

[bob]

Hi Miguel.

Go ahead and adjust the issue in Gaviota. I had to do it in Telepath a couple of years ago. Arena is not the only UCI GUI with that problem.

Charles

Why not get the Arena guys (and others) to fix the GUI to match the specifications, rather than making the programs match the interpretation? You could find yourself with cases that are incompatible if the standard is not adhered to.

I agree 100% with that.

Stockfish is an offender in violating the UCI standard too. Here is the relevant section of code:

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.

In Stockfish you you must match the exact case of the option and value or Stockfish won't honor it. This is the kind of bug that could cause you to lose games if you are dealing with tools that expect the standard to be respected. It has little affect in the case of Stockfish because most tools and GUI's retain the case sent by the engine, but they are not required to do so. But if you are setting up programs with configuration files you could easily get this wrong and I have been bitten many times by this bug which is so trivial to correct.

Sometimes you are tempted to make tools more forgiving with respect to standards, but I think this encourages non-adherence and makes the problem worse because people are sometimes not even aware there is a bug.

Personally I think UCI names and values should have been case sensitive, but it doesn't matter what I think, it's not.

Several years ago I tried to parse a huge database of PGN games and I had to continue to patch my parser to deal with the fact that the games were not proper PGN with respect to the SAN notation. It didn't just happen 3 or 4 times but it went on and on, I would fix one thing and then at some point someone thought of a different way to violate the standard. It was unbelievable how many ways castling was represented in this database, practically every combination of upper and lower case 'o' and the zero character as well as the hyphen missing or included arbitrarily and let's not forget "Kg1" was in there a few times to mean O-O. Also you would see N3d2 when Nfd2 was the correct disambiguation. I could go on and on. Fortunately we have good tools that can clean up some of these issue and you rarely see this any more.

I spent a ton of time on the same issue. From 1.e4 (should be 1. e4) to 15. 0-0 (should be 15. O-O, which is letter O, not zero). Bogus comments. improper nesting of comments. Missing tags. e2-e4. the list goes on and on. The standard is specific. But the standard-breakers were not put off by a mere standard and did what they wanted anyway. ChessBase included. It is pretty well out of control...