Stockfish Syzygy: how to interpret mates?

[hgm]

If the position is a 50-move draw (i.e. not enough moves left to convert the win) you will see +0.01 or -0.01.

Couldn't you make this depend on the number of moves that you are short of a win? So that the user can follow how the engine is catching up against a sub-optimal defender?

[syzygy]

UCI does not allow outputting "tablebase win after 3 moves".

Uh? How about "info string tablebase win after 3 moves"

Sure, but that's not what I meant. But this could be a way to get the information to the user, yes.

Note that it quite usual that engines report mate scores that are not the fastest mate (for over-the-horizon mates, discovered by hash grafting), so I don't know why that would confuse the end user more than any other mate score. Mate scores always mean 'mate in at most ...'.

The mate scores posted by the OP were probably correct as upper bounds, but did confuse.

I would have WinBoard print DTC's reported by the engine with the other engine output...

This might be a silly question, but does the xboard/winboard protocol allow the engine to print mate scores (or even "tablebase win" scores)? According to this page, score is an integer giving evaluation in centipawns.

Anyway, it seems to me that it is more an interface decision whether to show this to the user, and that the engine should dutifully report it. The enfine can pirnt

info dtc N ....

as PV info (which should be ignored by UCI-compliant interfaces that don't know what dtc means), or, more conservatively

info string dtc N

just before the PV info.

But then there should be some (not necessarily universal) agreement between engine and gui authors.

In case we are going to redo UCI, I would like to ask for the possibilty of defining a hierarchy of options (e.g. Syzygy.Path, Syzygy.ProbeLimit that all appear under a button "Syzygy").

[syzygy]

If the position is a 50-move draw (i.e. not enough moves left to convert the win) you will see +0.01 or -0.01.

Couldn't you make this depend on the number of moves that you are short of a win? So that the user can follow how the engine is catching up against a sub-optimal defender?

That's an interesting idea. Unfortunately my tables do not distinguish between a 50-move draw in the current phase and a 50-move draw in a later phase. So I might only know that either there are 20 moves to go to a next phase that needs > 50 moves (with no known upper limit) or there are 70 moves to go in the current phase to get to the next phase.

But if I restrict this to positions that are actually won except that the current DTZ50 value exceeds the number of moves left, then it should work fine. This would keep the range of possible values reasonably small, so that it should not be too confusing.

[syzygy]

But if I restrict this to positions that are actually won except that the current DTZ50 value exceeds the number of moves left, then it should work fine. This would keep the range of possible values reasonably small, so that it should not be too confusing.

I've now implemented this. If a position needs 40 moves to be won, but the move counter is already at 15 moves, the reported score is now 0.45.

[Vinvin]

But if I restrict this to positions that are actually won except that the current DTZ50 value exceeds the number of moves left, then it should work fine. This would keep the range of possible values reasonably small, so that it should not be too confusing.

I've now implemented this. If a position needs 40 moves to be won, but the move counter is already at 15 moves, the reported score is now 0.45.

0.45 is low for a winning position ... may be *10 and add +20 -> 24.50

[RJN]

I wish it were an adjustable option, so that we end-users could decide when we wished to be confused or not

I am open to your suggestions.

Note that each UCI option uses valuable screen space in the engine configuration window, so there must be a clear added value for each option.

What is the value of knowing that the current position has a DTZ of 8, or 5, or 22? I suggest that it's a fairly meaningless statistic, wouldn't you agree?

Hi Robert. I didn't think the "screen space" would be an issue, since H4 has fewer parameters vs H3, I believe (only one probe setting now, and no Scorpio cache).

As H.G. Muller pointed out, I think being able to see the Syzygy output has merit:

I don't think so. It tells you when to expect progress. When it says DTC = 22 it is obvious that it will be tedious and I'd brew a cup of tea, when it says DTZ = 3, I can wait for 3 moves to see if the DTZ changes into a mate score, or what the new DTZ will be.

Anyway, no biggie, and so far I am liking H4 very much, thanks.

[Dirt]

I've now implemented this. If a position needs 40 moves to be won, but the move counter is already at 15 moves, the reported score is now 0.45.

0.45 is low for a winning position ... may be *10 and add +20 -> 24.50[/quote]
But this is a drawn position. The 0.45 score seems reasonable.

[Vinvin]

I've now implemented this. If a position needs 40 moves to be won, but the move counter is already at 15 moves, the reported score is now 0.45.

0.45 is low for a winning position ... may be *10 and add +20 -> 24.50

But this is a drawn position. The 0.45 score seems reasonable.[/quote]
Thanks to correct me, I've a pharyngitis for 3 days and I'm not very lucid now ...

[hgm]

This might be a silly question, but does the xboard/winboard protocol allow the engine to print mate scores (or even "tablebase win" scores)? According to this page, score is an integer giving evaluation in centipawns.

The standard does not currently define it, but the standard is alive, and not cast in stone. Mate scores can be encoded as numbers without breaking interfaces that would not know about this extension of the standard. Like 1000000+x for mate in x, and -1000000-x for mated in x. Similarly, scores +/- (800000+x) could be used for encoding DTZ, and +/- (900000+x) for DTC, etc.

An important consideration is that it only has to be implemented in WinBoard and Polyglot to automatically work for all UCI engines.

But then there should be some (not necessarily universal) agreement between engine and gui authors.

Well, you have to start somewhere, and Stockfish is as good a place as any. If everyone keeps looking at the other until a standard emerges, while none is proposed, and none is being negociated, there will certainly never be any progress.

In case we are going to redo UCI, I would like to ask for the possibilty of defining a hierarchy of options (e.g. Syzygy.Path, Syzygy.ProbeLimit that all appear under a button "Syzygy").

You mean a button to open a child dialog?

That also seems an interface feature to me, not necessarily related to the protocol. Names can already consist of multiple words in UCI, and a space seems as good a delimiter as a period. You can simply call the options "Syzygy Path" and "Syzygy ProbeLimit", and if the GUI thinks it would be worth creating a separate dialog for that (because there are many, and because there are also many non-Syzygy options), it could do that. All within the framework of existing protocol.

WinBoard currently would not create any child dialogs, but it would already draw a Windows group box around the options, with the name Syzygy (the longest leading string the options all have in common), and then list all the options within the group box without the leading Syzygy. This is why the Polyglot options always appear in a separate groupbox in the Engine Settings dialog. These all have names "Polyglot XXX", and this makes WinBoard decide to group them. Making it into a separate child dialog would only be a small step. But not something the engine would have to know about.



I resisted the temptation to allow WB engines to define options of type Label and (column-)Break, etc., which WinBoard/XBoard uses in addition to the UCI standard types to define its own dialogs. Because I don't think it is a good thing to allow the engine to meddle in GUI matters.

I did define an option type ('Reset') that (on activation) would prompt the engine for completely resending its list of options + settings. It was originally intended to allow engines to implement a button to reset everything to their defaults, without the GUI having to remember those defaults. But it is much more flexible than that, as an engine could have several options of that type (but different name), to recall one of several 'profiles' (groups of settings) with a single button. And it could even be used to not only alter the values of existing options, but actually completely redefine the list of available options. This would allow the engine to create a button 'Advanced' with its initial options, to greatly expand the number of options when it is pushed (and amongst these new options, a button 'Basic' to go back to the smaller number of options). It could also be used for something similar to what you suggest: amongst the initial options the engine would only define a single reset button "Syzygy", and when it is activated, it would redefine the option to a list of the real Syzygy options only (plus a 'Close' button). They would then not appear in a child dialog, but just replace the controls in the current Engine Settings dialog, until you press 'Close', after which the engine would redefine the list back to the initial one.

[syzygy]

In case we are going to redo UCI, I would like to ask for the possibilty of defining a hierarchy of options (e.g. Syzygy.Path, Syzygy.ProbeLimit that all appear under a button "Syzygy").

You mean a button to open a child dialog?

That also seems an interface feature to me, not necessarily related to the protocol.

The button and child dialog implementation is an example. How to handle a hierarchy of options would be left to the GUI. But only the engine knows which options are hierarchically related, unless this is somehow communicated to the GUI, e.g. via a naming convention.

I do think this is a change of the protocol in the sense of the agreement that exists between engine programmers and gui programmers. The good thing is it's backwards compatible.

I think it would be a nice way to overcome the problem of lack of screen space in the engine configuration window that apparently exists at least in some GUIs.

A way of indicating advanced settings would also be nice. How to deal with advanced settings is up to the GUI, but only the engine knows which settings are advanced and which are not.