UCI issues

[mhalstern]

To elaborate on my last post:

gaviota crashes Aquarium, even when gaviota has the black pieces! Whether gaviota has white or black, as soon as I click "OK" to start the engine match, instead of the "Observe" button showing and moves being shown on the board, nothing happens.


I tried an interesting experiment:

I had rybka play white and gaviota black and tried to start a match. I set both sides to not use books and G12. After Aquarium crashed, rybka was showing 0% cpu usage, but gaviota showed full usage. I killed the gaviota process with task manager, then rybka eventually made a move, showing on the gui.

[michiguel]

I replied to you P.M., but as it does not leave my outbox, I'm not sure the pm feature is workign now. Here is my reply:

I got the PM too. It leaves your outbox when I read it, I think.

Let me know how I can further troubleshoot this for you.

You did a lot already. I think I figured it out (at least partially).

The name ID in communication protocol is NOT case sensitive, and aquarium decided to be creative and deviate from the examples in the protocol. For instance, rather than sending "name Ponder", it sends "name ponder". It is my fault, but... why is aquarium trying to go into the corners of the protocol?
Still, I feel this is not the only problem. I do not discard the possibility that there is a problem with Gaviota.

Anyway, what is the point of making a protocol case insensitive?

Clearly, the demo does not work like the paid version, either.

Miguel

[Dann Corbit]

I replied to you P.M., but as it does not leave my outbox, I'm not sure the pm feature is workign now. Here is my reply:

I got the PM too. It leaves your outbox when I read it, I think.

Let me know how I can further troubleshoot this for you.

You did a lot already. I think I figured it out (at least partially).

The name ID in communication protocol is NOT case sensitive, and aquarium decided to be creative and deviate from the examples in the protocol. For instance, rather than sending "name Ponder", it sends "name ponder". It is my fault, but... why is aquarium trying to go into the corners of the protocol?
Still, I feel this is not the only problem. I do not discard the possibility that there is a problem with Gaviota.

Anyway, what is the point of making a protocol case insensitive?

To introduce lots of very subtle bugs, obviously.


The fun part is that you can't simply lcase everything because Kb3 is not the same as kb3. So it is case sensitive sometimes.

Clearly, the demo does not work like the paid version, either.

Miguel

[mhalstern]

Miguel,

If you decide to modify the UCI version to try and get it working with aquarium, P.M. me another link and I'll test it.

A few questions:

Is this version 100% identical to the WB 0.74 version, except for the UCI stuff, or were there and search, and, or eval changes? Also, if you decide to release this, will there be a 64 bit version.

Anyway, the general UCI handling is good, as Fritz12 had no problems with it.

[michiguel]

I just saw that Aquarium demo does not even respect the engines time management. Rather than waiting for "bestmove <move> ponder <move>", it sends a brutal "stop".

It does the same in infinite analysis after 2 seconds. Hence, "demo".

This stop it is not sent in analyze mode, it is sent during the game and way after 2 seconds. I do not think that games are handicapped in this demo. If anybody runs a game with inbetween+anyUCIengine in the latest version we could find out for sure.

Miguel

You were right Teemu, the demo stops the engine at 2 seconds even during games. I looked at the wrong number before. So, I guess that is good, but makes the demo completely useless for engine developers who want to test. There are other things that are different. The demo is case sensitive and apparently the paid version is not.

Miguel

[michiguel]

Miguel,

If you decide to modify the UCI version to try and get it working with aquarium, P.M. me another link and I'll test it.

I'll do that, thanks.

A few questions:

Is this version 100% identical to the WB 0.74 version, except for the UCI stuff, or were there and search, and, or eval changes? Also, if you decide to release this, will there be a 64 bit version.

Regarding eval and search, it will be 100% identical (I think). There are lots of minor changes and some features, the use of two book layers, excluding moves in analysis, the WB protocol was polished to make sure it is CM compatible, few issues regarding TB generation were taken care of, one important bug was fixed (it was dormant for several years and decided to show up in the first two rounds of WBEC tournament!), etc.

Eval and search changes are in a different branch of development. I want to release this version to have a better background version for incorporating eval and search changes. I do not have anything exciting yet (maybe ~40 elo points), but I need to tune a lot of things. Hopefully, after the next UCI release, I can focus on strength.

Anyway, the general UCI handling is good, as Fritz12 had no problems with it.

From the log you sent, I detected another problem between Gaviota and Aquarium, and this is a Gaviota bug. The unorthodox implementation of Aquarium exposed this bug. Aq. sends "go infinite" and "stop" at the beginning (tells the engine to analyze and stops it immediately). Gaviota receive the commands out of sync and that is why it remains in a analyze mode. A typical race bug (shame on me).

Miguel

[Jaap Weidemann]

The engine's only responsibility in this regard is to change its own internal workings when a setoption command is received. When the engine starts up the default values should always be assumed. In other words, it is up to the GUI to remember what values for the various options the user prefers. The GUI should send the changed options with setoption commands when the engine is loaded.

Engines could opt for having their 'default settings' configurable, though, through some ini file, rather than compiled in. If they do, it would only be natura to also provide a button option "Save Settings", which would trigger saving the current settings to the ini file, so that the user can edit the ini file through the GUI engine settings dialog. This way you could even make different sve buttons for sub-sets of the options, e.g. "Save Personality", to only save those settings that affect the playing style.

So I think it is very much a design choice of the engine author.

It is a excellent idea, but unfortunately most GUI's never check if the default values have changed. They build a list of the default options and subsequent values when the engine is installed and changes the values in the list only when the user changes an option value. Only values that differs from the default list built when the engine is installed is sent to the engine when it is initialised. Some GUI's even sends the whole list (as opposed to just the modified options) to the engine every time the engine is initialised. This renders the INI file useless unless the engine prefers the INI settings over its UCI counterparts. Which will in turn render the relevant UCI option(s) useless.

Jaap
http://www.weidchess.com/

I think that should obviously be counted as a GUI bug. (It would for instnce nt work properly at all when you replaced the engine executble by an update that has some different defaults.)

Not if the GUI checks the engine's id name string to establish if the engine version has changed (and if so rebuild the list of options and their values).

For your personality idea to work properly the GUI would have to store the default values (in addition to the user preferred values) and on every engine start compare the defaults to the stored defaults and change the user preferred values to the new default values if it finds that one or more default values changed.

The UCI protocol was designed around the philosophy that the GUI should handle as much as possible (including personalities), thereby decreasing the implementation burden on the engine author at the cost of control.

Jaap
http://www.weidchess.com/

[hgm]

A GUI could remember which settings were changed by the user, and use engine defaults for the settings that were not changed. This seems the proper way to design it.

[Jaap Weidemann]

The engine's only responsibility in this regard is to change its own internal workings when a setoption command is received. When the engine starts up the default values should always be assumed. In other words, it is up to the GUI to remember what values for the various options the user prefers. The GUI should send the changed options with setoption commands when the engine is loaded.

Engines could opt for having their 'default settings' configurable, though, through some ini file, rather than compiled in. If they do, it would only be natura to also provide a button option "Save Settings", which would trigger saving the current settings to the ini file, so that the user can edit the ini file through the GUI engine settings dialog. This way you could even make different sve buttons for sub-sets of the options, e.g. "Save Personality", to only save those settings that affect the playing style.

So I think it is very much a design choice of the engine author.

It is a excellent idea, but unfortunately most GUI's never check if the default values have changed. They build a list of the default options and subsequent values when the engine is installed and changes the values in the list only when the user changes an option value. Only values that differs from the default list built when the engine is installed is sent to the engine when it is initialised. Some GUI's even sends the whole list (as opposed to just the modified options) to the engine every time the engine is initialised. This renders the INI file useless unless the engine prefers the INI settings over its UCI counterparts. Which will in turn render the relevant UCI option(s) useless.

Jaap
http://www.weidchess.com/

I think that should obviously be counted as a GUI bug. (It would for instnce nt work properly at all when you replaced the engine executble by an update that has some different defaults.)

Not if the GUI checks the engine's id name string to establish if the engine version has changed (and if so rebuild the list of options and their values).

For your personality idea to work properly the GUI would have to store the default values (in addition to the user preferred values) and on every engine start compare the defaults to the stored defaults and change the user preferred values to the new default values if it finds that one or more default values changed.

The UCI protocol was designed around the philosophy that the GUI should handle as much as possible (including personalities), thereby decreasing the implementation burden on the engine author at the cost of control.

Jaap
http://www.weidchess.com/

A GUI could remember which settings were changed by the user, and use engine defaults for the settings that were not changed. This seems the proper way to design it.

In other words your idea is for the GUI to prefer option values changed in it to the changed defaults (INI option values). Therefore if the user changes an option value in the GUI and after change the same option's value to something else in the INI file, the INI value is ignored.

It does not matter how you implement it. If you store option values in more than one user editable location, situations will arise where both values will differ from the initial default value. In such a situation you'll have to discard one value in favour of the other. In synchronisation theory this is known as the set reconciliation problem.

This would probably be best solved by timestamp synchronization. Unfortunately this would only be possible with a UCI protocol change. It is therefore not a design choice of the engine author.

[hgm]

I don't think the protocol can be blamed for this. It is not the protocol that forces the GUI to store settings.

It is all a matter of persitence. If a user makes changes to the default settings, would he want these to persist in later sessions, or would he like to start a new session again with the defaults. What is preferable often depends on the option.

With engine-defined options, the GUI cannot know what the most sensible behavior would be. So the responsibility should be with the user, to inform the GUI every time he changes a setting if he want this change to apply permanently, or if it is just a one-time thing. If it is a one-time thing, the GUI should make the choice in favor of the engine defaults (possibly from an engine INI file), if it is persistent, it chooses for the settings stored in its own database.