Winboard Forum

The "egt" feature is supposed to list the tablebase formats that an engine supports.

I think Arasan is one of the few xboard native protocol engines that supports more than one format (Gaviota
and Nalimov; the dev version on github supports Syzygy, too).

But the UI doesn't seem to deal with this feature in a useful manner.

First, the tablebase options are in the "Common Engine Settings" dialog. But if there
are two engines in use, and they support multiple tablebase types, then you could
have one engine set to use Nalimov and another set to use Gaviota tbs, in principle.
But as far as I can tell the UI will not let you do this.

Also the choices listed in the egt feature are not shown to the user anywhere. Winboard
(4.7.2) only shows "EGTB Path" and "EGTB Size" as options in the common engine dialog.
xboard (4.7.3) shows "Nalimov EGTB Path" and "EGTB Size" as options, even though the
egt feature string is "nalimov,gaviota".

I guess I could define custom xboard options to set the tablebase type, path and other
options (this is what Arasan does in UCI mode) but if I am going to have to do that, then
what is the use of the "egt" feature?

The EGTB path text entry in the Common Engine Settings dialog should display the -egtFormats setting in WinBoard 4.8.0 if the deprecated option -defaultPathEGTB (which was the Nalimov path) is defined as an empty string. When used as input it triggers on the "flavor:" prefix to a path name to recognize it as a value to assign to -egtFormats. With the -egtFormats you can specify as many EGT flavors as you want (separated by commas):

syzygy:H:\dtz,scorpio:F:\bitbases

WinBoard will send egtpath commands for every flavor thus defined that is also in the engine's egt feature.So if different engines use different EGT flavors, and both are present on the machine (and WinBoard is made aware of their location), they should be able to do that. The engine can choose the flavor it likes most if there is more than one match. You could make an engine-defined option for helping it make up his mind; there is no provision for that in the protocol. There also is no standard provision for setting the EGT cache; just the memory command for specifying allowed total memory use, and the engine can allocate that to the various tasks as it deems best.

With all respect, that is really unintuitive. I see now from an earlier post that apparently you
can put the path string directly into the EGTB Path field of the dialog. But there's no
indication in the UI that the path field takes that syntax or can handle multiple types.

Also IMO it does not make sense to send multiple egtpath commands to the engine.
I can handle this but the engine can't access more than one tablebase type at a time,
so as you say it is assumed then it has a preference rule.

I think it would be better if the UI allowed you to specify the type to use and did so on a
per-engine basis, then sent only the selected type's egtpath. That also lets you select
different tb types for each engine and be assured that your selection will be chosen. I guess
the path string could still be a global option though.

Well, The UI in general does not contain any information on what the setting of the various options mean. There are help files / man pages for that. It would be nice if you could right-click on every control to pop up a window that displays the relevant paragraph in the manual for that parameter. But at the moment that is only science fiction.

I don't think it would be so counter-intuitive if the UI already showed a setting of the required syntax in the EGTB path text entry, even if that was with path names to non-existent directories. I.e. preconfigure the settings in a useful way. The problem here seems to be that the -defaultPathEGTB option is pre-configured, and has priority for display over the -egtFormats option, so that it eclipses it. The policy of always trying to mimic old behavior as closely as possible in case of extensions obviously fails here. The priority should really be that the value of -defaultPathEGTB is only displayed if the -egtFormats string is empty, not the other way around.

The problem is further compounded by that we want to preserve the user's settings from previous versions when he upgrades to a new version. That really means we cannot pre-configure anything except options that did not exist before. All current WinBoard users are likely to have an empty -egtFormats string in their settings file, and WinBoard currently contains no mechanism to force a value on options that are currently empty strings. It would anger people that have set a value for -egtFormats if this value was overwritten by a dummy example for the syntax each time they upgrade. I guess a future version could make -defaultPathEGTB a volatile option (not saved in the settings anymore) so that it would quickly revert to its default value of the empty string, but when for whatever reason it would be non-empty after startup, append it, prefixed with the word "nalimov:" to the -egtFormats option, and then clear it.

I don't see the merits of what you propose. Why shouldn't an engine want to use multiple EGTs? This is not a certainty at all, and the UI should not enforce such a limitation on the engine. Most users want engines that play by (adjusted) DTM, if DTZ50 tells them the current value of the ply counter allows it. So the engine would have to probe both Syzygy for the DTZ50 and Nalimov for DTM. Or the engine might want to probe Scorpio bitbases in search and Nalimov when reaching the end-game. Or the user could have installed only 3-5men of the flavor the engine prefers, (Say DTM50), but 6-men of another flavor, (e.g. Syzygy) so that the engine would like to switch when reaching the 5-men stage. It is upto the engine to make such decisions, the UI should not cripple it by withholding information. If the engine wants to delegate this decision to the user, it can make an engine-defined option for this, as with every parameter it wants the user to set.

[Edit]I now pushed a patch that will still go into 4.9.0 for always clearing the -defaultPathEGTB option after appending it as nalimov to the -egtFormats, so that the 'EGT path' text entry in the Common Engine Settings now will always display the -egtFormats setting.

Ok, your patch improves things at least a little.

As to the utility of multiple tablebase types (simultaneously): I think I am practically the
only engine author who has implemented them (at least for non-UCI engines) and
so if I don't find them useful I am not sure who would.

--Jon

That no one does it (yet) still doesn't mean we should design interfaces to make the only correct way to do it impossible.

For XBoard right-click help might not be science fiction very long, BTW. It seems really easy to implement. I already have it such that almost every menu or dialog item pops up a window displaying its name. As the item names usually litterally appear in the manual as section headers, all I have to do now is look it up in the manual, and display the following paragraph in the dialog instead.