the consensus seems to be that "SyzygyPath" is better than "Syzygybases Path".
Would you consider switching to "SyzygyPath" to make engine and GUI programmers happy ?
Fine with me
Actually I don't like spaces in the middle of such names, but it seemed consistent with other Stockfish UCI variables.
Any proposal for "Probe Syzygybases"?
It is certainly possible to remove this, but it may be useful as a way of disabling probing without having to change the path, or of limiting probing to 5-piece tables (e.g. for comparison purposes).
Thanks !
ChessGUI will support "SyzygyPath" and "Probe SyzygyBases" (with "B", not "b").
syzygy wrote:Any proposal for "Probe Syzygybases"?
It is certainly possible to remove this, but it may be useful as a way of disabling probing without having to change the path, or of limiting probing to 5-piece tables (e.g. for comparison purposes).
Screen space is in high demand for the UCI configuration screen, it's always a good idea to keep the number of UCI parameters as low as possible - redundant UCI parameters will only clutter the configuration screen.
No extra parameter is needed for the usage you describe. Most users will keep the 3/4/5-men tablebases in a separate folder from the 6-men files, and select the appropriate folder(s) for analysis.
Note that currently your initialization function can only be called once, and that it's impossible to modify the SyzygyPath variable after the initialization. It would be a good idea that you modify this behavior, it is unexpected and undesirable for engine users (if you don't I will have to do this for the Houdini 4 release).
Houdini wrote:No extra parameter is needed for the usage you describe. Most users will keep the 3/4/5-men tablebases in a separate folder from the 6-men files, and select the appropriate folder(s) for analysis.
If they do that, the paramater is not needed. But setting a path variable is something that I would personally prefer to do only once, whereas I do sometimes want to limit the probes to 5 pieces or not probe at all.
On the other hand, maybe the usual solution for is to have different engine profiles, each with a different path? I'm not much of a GUI user.
Personally I would prefer an environment variable for the path and leave the path it out of the GUI altogether, but I understand this is not acceptable for UCI interfaces.
Anyway, what you do is up to you, of course.
Note that currently your initialization function can only be called once, and that it's impossible to modify the SyzygyPath variable after the initialization. It would be a good idea that you modify this behavior, it is unexpected and undesirable for engine users (if you don't I will have to do this for the Houdini 4 release).
The SyzygyPath option can be set multiple times now. This should not lead to memory leakage (and should not crash), but I am interested in hearing about any problems.
I looked again at the list of UCI options of Stockfish. It is clear that "Syzygy Path" would fit much better with the Stockfish way of naming UCI options than "SyzygyPath". Of course this is just cosmetic, and any engine author can pick whatever name he wants.
Is there a particular reason why engines should agree on UCI option names? Is this necessary for (some) GUIs? Wildly varying names will of course confuse users, but SyzygyPath versus Syzygy Path should not pose any problems.
If the option names are recognisable to the gui it might choose to automatically set them for the user when first setting up the engine's settings (rather than with multiple engines needing to enter the path for every one of them you setup)
kbhearn wrote:If the option names are recognisable to the gui it might choose to automatically set them for the user when first setting up the engine's settings (rather than with multiple engines needing to enter the path for every one of them you setup)
Exactly ! It saves a lot of work when configuring many engines.
"Syzygy Path" conforms with Stockfish alone, "SyzygyPath" conforms with GUIs and many engines.
ChessGUI will support "SyzygyPath" and "LimitSyzygyProbe".
Matthias Gemuh wrote:ChessGUI will support "SyzygyPath" and "Probe SyzygyBases" (with "B", not "b").
Let's remove that last space as well and name it SyzygyProbeLimit?
SyzygyProbeLimit sounds like an integer (3,4,5,6,...).
LimitSyzygyProbe sounds like a boolean (true,false).
Which one is valid ?
It's indeed an integer. Probes are only made for positions with at most SyzygyProbeLimit pieces. Setting it to 0 disables probing (and you don't have to change the path ).
Whether you should specifically support this option in your GUI is up to you. Users should normally of course let the engine probe all tables that are available (and my current fork now internally checks for up to how many pieces tables are available in order not to try 6-piece probes if only 5-piece tables are present).
I have some more ideas for useful options (e.g. an option to let the engine move immediately once in the tables instead of using something akin to crafty's swindle mode and an option to influence the treatment of detected 50-move draws). If that is burdensome for GUIs then:
- I can personally not care too much, because I am just maintaining an unofficial fork mainly intended to show how the tables can be used; developers with users to please are under no obligation whatsoever to do the same;
- still it would be nice if there were no barrier to adding useful options, e.g. if syzygy.path and syzygy.probelimit could be hidden under a button "syzygy" which would open all syzygy.* options.
