WB protocol (and UCI?) extension proposal

[michiguel]

Well, if it is also useful to have the opposite, then I would definitely prefer include/exclude over kille/unkill. So leave it as it is. Currently WinBoard does not implement this at all, and I will adapt to Gaviota. I only have implemented it in Polyglot as a "sleeper feature", using "kill". But then I will change that there to "exclude" (abandoning the fine tradition of WB protocol to have silly command names... ), and implement the "include" as well.

Currently I only tested the UCI searchmoves implementation in Polyglot using the synonym of the "exclude" command appearing as an engine-defined option in the Engine-Settings dialog. (It seemed to work with Glaurung: after 1. e4 f5 Glaurung likes 2.exf5, and typing e4f5 for the option made Glaurung switch to e5, and then typing e4e5 made it change to Nc3.)

A problem is still how to implement this in a game-state-unaware adapter like UCI2WB. I guess I will have to make it collect the move list from the engine's currmove commands. A rule-unaware GUI could then request it from the adapter. This has the advantage anyway that it could present the moves in engine-order, so that the most relevant moves presumably are near the top of any presented table. I am thinking of using the WB "bk" command for this, requiring an engine to send all legal moves from the current position when it receives it in analysis mode.

As to the "chat" stuff: I am not too keen on giving the engine a say in GUI matters. It should be the user's choice if he prefers to see white or black at the bottom, wants to see the PV as SAN or long-algebraic, or wants to see engine tells as popups or a chat (or not at all). The engine's task should be limited to providing content.

I know that XBoard has an option auto-comment, but I think this is not used outside ICS mode. It would be nice to also give it a meaning in engine mode, so that engine utterances could be incorporated in the PGN.

After opening gaviota and typing in the terminal

Code: Select all

help exclude

exclude <move1> <move2> etc.
exclude none
All the different moves will be excluded from analysis
all will be analyzed with the parameter 'none'
moves are in format e2e4, c7c8q etc.
see "include"

help include

include <move1> <move2> etc.
include all
All the different moves will be the only ones considered in analysis
all will be analyzed with the parameter 'all'
moves are in format e2e4, c7c8q etc.
see "exclude"

I think you have everything you need to test this. With inbetween you can force gaviota to send feature exclude=1, and replace "exclude" with 'kill", if you want. I can make this modifications in a breeze, but you can use it right away as it is now.

It is exactly the model Ferdinand suggested.

Miguel

[Karlo Bala]

Well, I am only relaying user requests, as I never do any analysis myself. But several people agreed that this is ssential, and multi-PV is way to slow. The problem is that multi-PV keeps wasting time on what the engine perceives as the best move, even when the user already decided there is no way he is going to play that.

Chess Genius had the "next best" option. I liked that feature.

[hgm]

At first I thought also that it would be enough to have a command to suppress the currently best move. But people who use this feature assured me that this would not do, and that it is important to be able to also knock out moves later in the list. The first tests I will probably do with an interface that allows the user to indicate the moves he wants to disable by playing them on the board (grabbing the piece with a double-click, rather than a single left-click). Because this is really easy to make. But I could also add a "next best" text in the Engine-Output window that you can right-click to kill the currently best move.

[Evert]

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

I find it confusing that the "feature" option is different from the actual command. This is inconsistent with existing feature options but I think it looks messy regardless of that.
Why not have "exclude MOVE" (or MOVES) rather than "kill MOVE"? To me at least it would also be more obvious than "kill"...

[hgm]

Well, this was already more or less agreed. So the modified proposal is:

engine->GUI:

feature exclude=1

sent at startup enables GUI->engine commands

exclude MOVE
include MOVE
include all

Note there only can be a single move per include / exclude, and that the effect is cumulative. For this reason I don't want an "exclude none". The MOVE will be in long algebraic format, irrespective of whether the engine requested SAN moves through feature san=1. (I consider this feature an abomination...)

No error handling is expected. If the engine is asked to exclude a move that is not legal or not even a move, it should just ignore the command altogether, In particular it should NOT send an "Illegal move:" command to instruct the GUI to take the move back, because the GUI would not have made the move in the first place. If the MOVE in an include command is not currently excluded, this can be ignored. Anyting that is not a move (except "all") is in principle reserved with undefined effects.

[michiguel]

Well, this was already more or less agreed. So the modified proposal is:

engine->GUI:

feature exclude=1

sent at startup enables GUI->engine commands

exclude MOVE
include MOVE
include all

Note there only can be a single move per include / exclude, and that the effect is cumulative. For this reason I don't want an "exclude none". The MOVE will be in long algebraic format, irrespective of whether the engine requested SAN moves through feature san=1. (I consider this feature an abomination...)

No error handling is expected. If the engine is asked to exclude a move that is not legal or not even a move, it should just ignore the command altogether, In particular it should NOT send an "Illegal move:" command to instruct the GUI to take the move back, because the GUI would not have made the move in the first place. If the MOVE in an include command is not currently excluded, this can be ignored. Anyting that is not a move (except "all") is in principle reserved with undefined effects.

For clarification:

You assume there is "two sets" of moves.
Set A: contains moves that will be considered at the root
Set B: contains moves that won't be considered at the root.
By default, all legal moves are in Set A.

exclude takes a move from set A to set B.
include takes a move from set B to set A.
include all takes all moves in set B and place them in set A. Of course the ones that were in set A, remain in A.

Is that correct?

That is fine, but just to clear, it is not what Gaviota does currently (I will need to modify it). Currently, include means that only the selected moves will be analyzed. In other words, there an imaginary "exclude all" that precedes the first include. Note that this is useful to work manually in the console, which was my intention.

Is this supposed to be sent in force mode or at any time of the search?
If this is could be sent at any time in the search, it would be a good idea to make this atomic. But maybe sending it only in force mode should be best?

Miguel

[hgm]

For clarification:

You assume there is "two sets" of moves.
Set A: contains moves that will be considered at the root
Set B: contains moves that won't be considered at the root.
By default, all legal moves are in Set A.

exclude takes a move from set A to set B.
include takes a move from set B to set A.
include all takes all moves in set B and place them in set A. Of course the ones that were in set A, remain in A.

Is that correct?

Indeed, this is what I intended.

My original idea for a GUI implementation would not use include at all. The user would indicate moves to be excluded by playing them on the board with some extra signalling (like keeping a key pressed, or starting with a double-click). The GUI would undo the move as soon as it is made, and send the exclude command for it.

Some time later (and considering the typical difference in clock speed between computers and humans, seen from the computer as an eternity) the user could then exclude another move, etc. I could not imagine why anyone would want to include a move back in once it is excluded, but never do this kind of stuff, so what do I know?

But if people want to have a 'palette' with all legal moves that they can disable or re-enable interactively at will, it seems easiest to immediately send include or exclude as soon as the user changes the state of a move.

The commands would only be sent in analysis mode. I don't see why that would be a problem. Switching to force mode to send them would require a new analyze command after it, which presumably would start a new search. If that is acceptable, the engine might as well start a new search on reception of any of these commands by itself. But I don't want to deny engines the right to be 'smart': when receiving an exclude for a move that is currently not best, and currently not being searched, they could just mark it as disabled in the root, but otherwise continue the current search.

[Piero]

Since a change is being discussed. I would like to suggest the possibility to exclude lines too, not just moves. I believe this would be way more useful for analyses.

[hgm]

Wouldn't the posibility to assign an arbitrary score to any given position already cover that? Just define the position at the end of the line as a loss, and the engine should stay away from it.

When you exclude a line, the engine would probably just switch to a transposition to get to the same position.

[michiguel]

For clarification:

You assume there is "two sets" of moves.
Set A: contains moves that will be considered at the root
Set B: contains moves that won't be considered at the root.
By default, all legal moves are in Set A.

exclude takes a move from set A to set B.
include takes a move from set B to set A.
include all takes all moves in set B and place them in set A. Of course the ones that were in set A, remain in A.

Is that correct?

Indeed, this is what I intended.

My original idea for a GUI implementation would not use include at all. The user would indicate moves to be excluded by playing them on the board with some extra signalling (like keeping a key pressed, or starting with a double-click). The GUI would undo the move as soon as it is made, and send the exclude command for it.

Some time later (and considering the typical difference in clock speed between computers and humans, seen from the computer as an eternity) the user could then exclude another move, etc. I could not imagine why anyone would want to include a move back in once it is excluded, but never do this kind of stuff, so what do I know?

But if people want to have a 'palette' with all legal moves that they can disable or re-enable interactively at will, it seems easiest to immediately send include or exclude as soon as the user changes the state of a move.

The commands would only be sent in analysis mode. I don't see why that would be a problem. Switching to force mode to send them would require a new analyze command after it, which presumably would start a new search. If that is acceptable, the engine might as well start a new search on reception of any of these commands by itself. But I don't want to deny engines the right to be 'smart': when receiving an exclude for a move that is currently not best, and currently not being searched, they could just mark it as disabled in the root, but otherwise continue the current search.

I think that the exclude/include commands should also be accepted both in force and analyze mode. I figure that many users will set a position, exclude/include, and then go to analyze.

Once in analyze, what happens if a move is exclude while it is being analyzed? I think the easier thing will be to request it is excluded it in the next iteration.

The GUI should make sure it never excludes all the moves, otherwise, that could cause problems, unless the protocol defines a behavior here. I know this is a silly situation, but a user could click off all the moves by mistake.

Miguel