WB protocol (and UCI?) extension proposal

[hgm]

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.

Well, then I think we might as well allow the commands in any mode. Because I can also see applications of exclude during a game, where the GUI could exclude moves that cause forbidden repetitions (i.e. perpetual chases) from the next search. So the engine should clear its list of excluded moves only when moving to another position (i.e. receiving usermove, undo, new, setboard).

Implementation of the feature is for a large part up to the engine. If the move it is now searching is excluded (which does seem a rather usual situation: engine gets a fail high on a non-PV move, starts a re-search with open window, user thinks "Oh no, not that!" and excludes it), the user would probably not be very happy if the engine spent another 15 minutes to finish the search of that move at a large depth. So the choice is between the simple implementation of aborting the search, restarting at d=1 (which you would also have to do whan the PV move gets excluded), or a "selective abort" which forces return from all levels but continues in the root.

I thought about the case where a user would exclude all moves, but I did not foresee a problem there. The engine would simply report a (stale)mate. That doesn't seem to need any special provisions; positions with zero moves could also occur without excluding any moves, and the engine should know how to handle those. Note this situation can only occur when the user excludes the current-best move from a situation where only a single move was left, which should start a new search at d=1.

[Michel]

Is it clear how this include/exclude stuff interacts with undo?

Undo happens often during analysis. Should the engine remember the included/excluded moves associated with a position, or is it the responsibility of the GUI to resend them?

[michiguel]

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.

Well, then I think we might as well allow the commands in any mode. Because I can also see applications of exclude during a game, where the GUI could exclude moves that cause forbidden repetitions (i.e. perpetual chases) from the next search. So the engine should clear its list of excluded moves only when moving to another position (i.e. receiving usermove, undo, new, setboard).

Implementation of the feature is for a large part up to the engine. If the move it is now searching is excluded (which does seem a rather usual situation: engine gets a fail high on a non-PV move, starts a re-search with open window, user thinks "Oh no, not that!" and excludes it), the user would probably not be very happy if the engine spent another 15 minutes to finish the search of that move at a large depth. So the choice is between the simple implementation of aborting the search, restarting at d=1 (which you would also have to do whan the PV move gets excluded), or a "selective abort" which forces return from all levels but continues in the root.

I thought about the case where a user would exclude all moves, but I did not foresee a problem there. The engine would simply report a (stale)mate. That doesn't seem to need any special provisions; positions with zero moves could also occur without excluding any moves, and the engine should know how to handle those. Note this situation can only occur when the user excludes the current-best move from a situation where only a single move was left, which should start a new search at d=1.

No problem with that, but I feel it should be specified and documented that there is a chance that all moves will be removed, so the engine should be prepared (i.e. not crash) and behave [insert here whatever it is decided].

Miguel

[michiguel]

Is it clear how this include/exclude stuff interacts with undo?

Undo happens often during analysis. Should the engine remember the included/excluded moves associated with a position, or is it the responsibility of the GUI to resend them?

Good point.
I think the GUI should resend this if needed.

Miguel

[hgm]

"undo" brings you to another position, and thus clears the exclusion map.

I have a trial implementation now at http://hgm.nubati.net/WinBoard-4.6beta.zip . It inverts the exclude status of a move that you play grabbingthe piece with a double-click.

It would, after all, be useful to also allow "exclude all". The trial version generates this when you drag a double-clicked piece off board.

[Michel]

"undo" brings you to another position, and thus clears the exclusion map.

But this feature would only be useful if the GUI resends the exclusion map right?


BTW I don't see why the xboard protocol cannot just use

searchmoves move1 move2 move3 ....

etc....

What is wrong with the way UCI does it?

[hgm]

But this feature would only be useful if the GUI resends the exclusion map right?

That is upto the GUI implementer. But XBoard only does it when the user again excludes the moves.

What is wrong with the way UCI does it?

It requires the GUI has know the rules. Or you would need some complicated method to obtain the move list from the engine.

[Michel]

That is upto the GUI implementer. But XBoard only does it when the user again excludes the moves.

I think this is not useful. In analysis you typically go back and forth (exploring some promising lines and then returning to the root position).
Having to recreate the exclusion map each time would be very cumbersome.

It requires the GUI has know the rules. Or you would need some complicated method to obtain the move list from the engine.

I guess there is no point arguing this.

[hgm]

I think this is not useful. In analysis you typically go back and forth (exploring some promising lines and then returning to the root position).
Having to recreate the exclusion map each time would be very cumbersome.

Well, like I said, this is a GUI implementation matter, not a protocol matter. UCI engines definitely do not remember the exclusion map for a position after you stop the search. In fact they do not even remember the position itself! Is there really any GUI that keeps an exclusion map for every position, not only in the game, but also in all variations?

I guess there is no point arguing this.

You guess right. It really gets immensely more complex when you do it the wrong way around.

[Michel]

Is there really any GUI that keeps an exclusion map for every position, not only in the game, but also in all variations?

I don't really know. Perhaps users of other GUI's can comment?


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