WB protocol (and UCI?) extension proposal

[dadij]

Update: at the risk of saying something stupid: it appears from the description here that in Aquarium the excluded moves are indeed attached to the position

http://aquariumchess.com/tiki/tiki-index.php?page=IDeA

This applies to IDeA analysis where the moves are excluded permanently. You can either specify the moves you want to exclude or the moves to be included in the analysis.

If you exclude a move manually from infinite analysis, it is not stored when you move to a new position and later go back to the original position.

You can, however, tell Aquarium to ignore moves in the Tree window from analysis or vice versa, i.e. only analyze such moves. This setting is maintained when you move to a new position.

[Ferdy]

It seems that WinBoard protocol does not provide any feature equivalent to UCI "searchmoves", which limits an analysis search to a given subset of root moves. People using engines for analysis seem to consider this a feature of crucial importance. In addition, it seems to be important to be able to assign scores to certain positions in the tree by hand. (A manual form of EGTB probing, as it were.) Some engines support a "session file" for this, and it seems desirable to have GUI support for manipulating the contents of this file.

What I propose is to add a new GUI->engine command

kill MOVE

which the GUI could use on engines that at startup say

feature exclude=1

to strike the mentioned root move from the current search. (Presumably this would mean that the search of the remaining moves would be restarted at low depth, but in cases where the previous iteration already had another move as best, it would be perfectly allowed to start from that iteration.)

Note that the Polyglot included with WinBoard 4.6.0 can also do this through an engine-defined option, called "Polyglot exclude move", which can be set by hand through the Engine Settings dialog, but for the GUI to use this command in response to some user mouse action, it seems better to enforce some standardization. This standardization could of course also be achieved by requiring the engine-defined option to have a specific name, but that goes a bit against the design philosophy of WB protocol.

For the session-file stuff I am less certain. The variety of implementations of this found in different engines is likely to be wider, making the use of an engine-defined option more natural. Also because in the most elaborate implementation, allowing the user to specify a score and depth to a given position, inherently seems to require keyboard input. And the Engine Settings dialog would be as good a popup for this to enter the required info as any.

There is one case where I imagine GUI assistence could be useful, though: the existing Adjudicate to White/Black and Adjudicate Draw items in the WinBoard Action menu could be used in a natural way to define the score of the current position as +/-30000 cP or 0, respectively, valid to any depth. But to achieve that, the GUI would need to know what option to send.

So it would seem useful to define an engine->GUI command

setscore SCORE DEPTH

which tells the engine to include the current position in its session file with SCORE centi-Pawn (from side-to-move POV, as always in WB protocol) with a depth limit of DEPTH ply. This would be subject to an initial

feature setscore=1

WB engines could use these options without problems, but setscores would only be implementable in Polyglot if there also was standardization of this option on the UCI side. (For "searchmoves" there already is.) I therefore want to propose UCI engines, wanting to make their session file approachable to the user through the GUI interface, would (as a minimum) supply the option

setoption name UCI_setscore SCORE

after the usual announcement

option name UCI_setscore type spin default 0 min LOSSSCORE max WINSCORE

so that Polyglot would know how to translate the setscore command. (Use of this option would imply validity of the given score to infinite depth.) It is up to the engine what other options it wants to provide for allowing the user access to its session file, and how long the effect of using the above option should last. (E.g. if there are buttons to clear (parts of) the session file, or save changes in it on a user-specified file.)

I tried the 4.6 beta include and exclude commands using winboard, and looks pretty cool . I would like to suggest to add command "include all" to be sent to the engine so that all moves that are excluded will be cleared. This is especially useful when user tries so many exclude and may forget how to include individually or it may take time to include again the excluded moves. It would be better to include everything in 1, 2 or 3 clicks, like double clicking the king of the side to move and another 1 click to same square of king or any other way you may like.

The following features are new in XBoard 4.6.beta:

Excluding moves from an analysis

Some engines allow the user to restrict the moves searched in the root position to a subset of all legal moves. XBoard now provides an interface for the user to indicate which moves should be excluded. The method used is to enter the move starting with a double-click on the piece. So either double-click from-square, and then click to-square, or grab the piece with a double-click, and then drag it to the to-square before you release for the second time. In the latter case there will be an visual cue to remind you that you are not really making the move, namely that the piece you start dragging will also remain on the from-square.

The first time you make a move that way in analysis mode, it will be excluded from the analysis of the current position. A new command had to be added to WB protocol to make this possible, and that command ("exclude MOVE") will be sent to the engine. The move will be highlighted in premove highlight colors (normally red). When you enter an excluded move in the double-click way again, its exclusion is cancelled (through sending "include MOVE" to the engine), and the move will remain highlighted in the normal highlight color (yellow).

[hgm]

I think the beta version already does this. If you throw a double-clicked King off the board vertically, it excludes all moves, but when you through it over the side edges, it includes all moves again. Probably I will have to find something better for this, because it feels quite unnatural. And the double-clicking when throwing the King off-board is also not really necessary, (and I consistently forget it).

What I really want is to have an extra header line in the Engine-Output window, containing some relevant moves, on which you can then right-click to include or exclude them. This then also would have an 'all', 'next-best' and 'best-only' in it, and perhaps 'tail' to include or exclude all moves not explicitly displayed.

The problem is how to figure out which moves to display there. WinBoard has no idea which moves are good or bad (or even legal, when legality testing is off). So it would have to rely on the engine. It could list moves that have been reported best in any of the previous iterations (occurred as first move in a PV). It could also just start listing a move there that the user excluded, but keep them listed when they are re-included. E.g. print -Nf3 if Nf3 is excluded, and +Nf3 when the user re-includes it, so that the user from that point can include or exclude it just by clicking on the move. This would also give the user some overview over what is currently excluded. If he would click 'next-best', the first move of the last-received PV would be excluded, and it would get listed as such if it was not yet in the list. Clicking 'best-only' would switch any explicitly listed moves (except the current best) off, and +tail to -tail, to indicate everything is off.

I don't mind if WinBoard would now and then re-order the moves in that line, but I don't want the line to change 'asynchronously' (because a new engine PV gets in), because the user might just be clicking it at that time. So a new make-up of the header line would be only allowed in reaction to the user doing something.

[hgm]

I uploaded a new beta version, which (apart from the double-click-drag method described earlier) offers the possibility to control the exclusion state of moves from a header line in the Engine Output window:



This replaces the kludge of dragging the King off board: you can now right-click on 'none' to include all moves, and on '+tail' to exclude all moves not explicitly listed (which initially would be all). You also can click on 'best' to exclude the current best move. Clicking on a listed move toggles its state. Moves get listed because you excluded them through the board, or because they were an excluded current-best move.

[Ferdy]

I uploaded a new beta version, which (apart from the double-click-drag method described earlier) offers the possibility to control the exclusion state of moves from a header line in the Engine Output window:



This replaces the kludge of dragging the King off board: you can now right-click on 'none' to include all moves, and on '+tail' to exclude all moves not explicitly listed (which initially would be all). You also can click on 'best' to exclude the current best move. Clicking on a listed move toggles its state. Moves get listed because you excluded them through the board, or because they were an excluded current-best move.

Thanks this works . I have not implemented the exclude all, what I have is include all, include move and exclude move. Also making a move on the board will reset everything.

[hgm]

Exclude all is only needed to exclude the tail. This is implemented by sending an 'exclude all', followed by 'include' for any move that was listed as 'included' in the header. I saw no other way to do that without the GUI having to know all moves.

The 'include all' command is both used when you click 'none' and to re-include the tail. In the latter case it is followed by an 'exclude' on all individual moves that were listed in the header as excluded.

Moving and 'undo' are indeed supposed to clear the exclusion set.

[Ferdy]

I am confused by the tail, everytime I pick it it will send exclude all command, then followed by include move command. In the beginning, after hitting analyze mode, and right clicking the tail, exclude all is sent followed by include move, this move is the move that is currently analyzed. Although the command is exclude all, never will there be time that the engine will be in idle, there is always at least a single move that is analyzed . Alright I will try to implement exclude all.