WinBoard protocol extension proposal: exclude moves

[hgm]

When analyzing a position with an engine, it can sometimes be convenient to forbid certain moves in the root. In UCI this can be done through the searchmoves command. Current WinBoard protocol does not have anything similar.

Now UCI searchmoves is a but clumsy, as you have to list all moves that you do want to consider, while what you usually want is to exclude moves.(If you want to search a specific move, you just play it, and analyze the daughter position...)

To provide this functionality, I wanted to propose the following new GUI->engine command for WB protocol:

setscore DEPTH SCORE MOVE

This would request the engine to store the position after the given MOVE in its hash table with a score and depth such that a hash hit on it from the current root position would be valid until the given root DEPTH, and produce the given SCORE in the root. (In other words: in normal negamax, when the engine counts in integer plies, and the MOVE in question is not extended or reduced as PV move, you would store it with -SCORE and draft = DEPTH-1.)

SCORE would be given in centi-Pawn, as usual.

This does not seem very difficult to implement in engines:

Just do MakeMove(), StoreHash(DEPTH-1, -SCORE, EXACT), UnMake();

The exclusion of moves could be acheived by setting SCORE = -INFINITE and DEPTH = +INFINITE, where INFINITE is some large value (the engine is supposed to correct overflowing values to its own representation of infinity). The move would then always produce a hash hit valid to any depth, and a score that causes it to be rejected immediately. But by given a finite score, you could make the exclusion conditional, so that the move becomes eligible when all others areunexpectedly poor. Or above a certain depth. The latter would be useful when you want to continue an analysis you made on an earlier day, and remember the score/depth of that analysis, (or have the GUI remember it for you), but now want to consider alternatives, without redoing the earlier analysis.

Of course the command can also be used to clear a hash entry, by using itwith DEPTH zero.

Feedback is welcome.

[pkappler]

I'd much rather specify the moves I want to search than the moves I want to exclude. For most positions, the former is a small number (2-3) while the latter is quite large (30+). This is certainly the case when I'm doing opening analysis and focusing on moves recommended by theory. Another common use case is to spend a few minutes with an engine in multi-pv mode, realize that there are only 2 good moves in the position, and then have the engine analyze those moves exclusively.

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

By the way, thank you for all the great work you've done on Winboard/Xboard. My only feature request would be support for multiple, simultaneous engine-vs-engine matches, similar to the -concurrency flag in cutechess-cli.

[hgm]

I'd much rather specify the moves I want to search than the moves I want to exclude.

But WinBoard protocol already has a command for that: "usermove XXX". That makes the engine search that move. This new command is intended for situations where you want the engine to figure out the next-best move.

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

The idea was that you could make it easy to suspend and resume an analysis. A long search could be picked up where you left off when you swtched off the computer, by having the GUI load back the stored results. For this the user would have never to see the scores. But ofcourse a user could also be used as storage medium: if he remembers from the previous day that the best move at 24 ply had a score 0.30, he could be allowed to enter that infoabout the move, so that in a multi-PV search he subsequently starts, no time has to be spent on this move until depth 25 is reached. That does not seem so difficult fora user to understand.

By the way, thank you for all the great work you've done on Winboard/Xboard. My only feature request would be support for multiple, simultaneous engine-vs-engine matches, similar to the -concurrency flag in cutechess-cli.

What is wrong with starting multiple WinBoards for that? I do that all the time.

[michiguel]

I'd much rather specify the moves I want to search than the moves I want to exclude. For most positions, the former is a small number (2-3) while the latter is quite large (30+).

For a user, both are needed. Many times I just want to exclude one move.
For a protocol, it does not make a lot of difference because you can achieve the same, but it may not be a bad idea to implement both.

This is what I have in Gaviota (console)

Code: Select all

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"

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"

No I realized the help is poorly written, but exclude none and include all reset any previous include or exclude command. Exclude none is identical to include all. I just implemented it for the sake of symmetry but it is not needed.

Once I applied the exclude or include command, I could do analyze, exit, etc. To me, this has been very useful.

This is certainly the case when I'm doing opening analysis and focusing on moves recommended by theory. Another common use case is to spend a few minutes with an engine in multi-pv mode, realize that there are only 2 good moves in the position, and then have the engine analyze those moves exclusively.

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

I do not believe this setscore command is a good idea because it deals with internal things of the engine. For instance, you may want to include or exclude moves and search with engines that do not even have hashtables (or are at an early stage of development). In my specific case, in Gaviota I do not probe the table at ply 1 for other reasons (related to 3 reps etc.).

Miguel

By the way, thank you for all the great work you've done on Winboard/Xboard. My only feature request would be support for multiple, simultaneous engine-vs-engine matches, similar to the -concurrency flag in cutechess-cli.

[hgm]

I do not believe this setscore command is a good idea because it deals with internal things of the engine. For instance, you may want to include or exclude moves and search with engines that do not even have hashtables (or are at an early stage of development). In my specific case, in Gaviota I do not probe the table at ply 1 for other reasons (related to 3 reps etc.).

Well, how the engine would implement it would be upto the engine author, of course. The official definition of the command would be to assign a given value to a position after the move. You could implement it by specialcodein the root to check the moves against a list you maintain outside the hash table, and take the score from there. How long the effect of the command shouldlast could be weakly specified ('as long aspossible'). Engines with non-standard implementations wouldjust show up to the user as more difficult to control by the GUI. Commands intended to save time would save less timeon them. Just as they would notice engines without hash table (or with a fixed-size smallone) would take longer to reach the same depth as engines with.

[pkappler]

I'd much rather specify the moves I want to search than the moves I want to exclude.

But WinBoard protocol already has a command for that: "usermove XXX". That makes the engine search that move.

Are you suggesting that the Winboard equivalent to 'searchmoves a b c' is 'usermove a', 'usermove b', 'usermove c'? In other words, do 3 separate searches, in succession? And the user is responsible for deciding when to terminate each of those searches? Perhaps I'm misunderstanding.

This new command is intended for situations where you want the engine to figure out the next-best move.

I see. I've never used an engine that way. If I'm interested in finding the best 2 or 3 moves, I just use multi-pv.

By the way, thank you for all the great work you've done on Winboard/Xboard. My only feature request would be support for multiple, simultaneous engine-vs-engine matches, similar to the -concurrency flag in cutechess-cli.

What is wrong with starting multiple WinBoards for that? I do that all the time.

That works well if your workload is easy to split evenly across multiple cores. This isn't always the case, especially if you play matches at different time controls. It's not too hard to manage on a 2 or 4-core machine, but my next computer will have 8 or 12 cores, and at that point, it'd be wonderful if Winboard could do the load-balancing for me.

[michiguel]

I'd much rather specify the moves I want to search than the moves I want to exclude.

But WinBoard protocol already has a command for that: "usermove XXX". That makes the engine search that move. This new command is intended for situations where you want the engine to figure out the next-best move.

It is more uses than that. For instance, I could want to search only two or three moves to choose from them, or exclude all the moves that lead to particular type of game (it could be more than one). I cannot do that with usermove.

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

The idea was that you could make it easy to suspend and resume an analysis. A long search could be picked up where you left off when you swtched off the computer, by having the GUI load back the stored results. For this the user would have never to see the scores. But ofcourse a user could also be used as storage medium: if he remembers from the previous day that the best move at 24 ply had a score 0.30, he could be allowed to enter that infoabout the move, so that in a multi-PV search he subsequently starts, no time has to be spent on this move until depth 25 is reached. That does not seem so difficult fora user to understand.

The winboard protocol has a command 'pause' that will tell the engine to freeze the search to be continued later. I implemented that in Gaviota because it is extremely useful. Unfortunately, it is not implemented in the GUI..

Miguel

By the way, thank you for all the great work you've done on Winboard/Xboard. My only feature request would be support for multiple, simultaneous engine-vs-engine matches, similar to the -concurrency flag in cutechess-cli.

What is wrong with starting multiple WinBoards for that? I do that all the time.

[michiguel]

I do not believe this setscore command is a good idea because it deals with internal things of the engine. For instance, you may want to include or exclude moves and search with engines that do not even have hashtables (or are at an early stage of development). In my specific case, in Gaviota I do not probe the table at ply 1 for other reasons (related to 3 reps etc.).

Well, how the engine would implement it would be upto the engine author, of course. The official definition of the command would be to assign a given value to a position after the move. You could implement it by specialcodein the root to check the moves against a list you maintain outside the hash table, and take the score from there. How long the effect of the command shouldlast could be weakly specified ('as long aspossible'). Engines with non-standard implementations wouldjust show up to the user as more difficult to control by the GUI. Commands intended to save time would save less timeon them. Just as they would notice engines without hash table (or with a fixed-size smallone) would take longer to reach the same depth as engines with.

It is not clear to me what the advantage is to specify that a subsequent position should not be reached compared to telling not to search a particular move (which will reach that position). If I want to exclude a move, why not telling the engine directly rather than using an indirect approach? Many engines are UCI/Winboard. They could apply the UCI procedure in a very quickly rather than implementing a complete different approach.

Miguel

[hgm]

It is more uses than that. For instance, I could want to search only two or three moves to choose from them, or exclude all the moves that lead to particular type of game (it could be more than one). I cannot do that with usermove.

Sure you can: 3x usermove, and 3x undo...

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

The winboard protocol has a command 'pause' that will tell the engine to freeze the search to be continued later. I implemented that in Gaviota because it is extremely useful. Unfortunately, it is not implemented in the GUI..

Indeed, pause could be implemented too. But to really make it work would be a bit of a hassle. You would have to save the entire hash table, for instance. But setscore would have other uses, and pause only one. You can do everything with it you can do with searchmoves, and more.

It is not clear to me what the advantage is to specify that a subsequent position should not be reached compared to telling not to search a particular move (which will reach that position). If I want to exclude a move, why not telling the engine directly rather than using an indirect approach? Many engines are UCI/Winboard. They could apply the UCI procedure in a very quickly rather than implementing a complete different approach.

Not searching a position and not searching a move is equivalent. That is not the difference between searchmoves and setscore. That equivalence is also reflected in the syntax. In both cases they contain a move, not a position. The difference is that with setscore you can exclude the move conditionally: upto a certain depth. And the method of storing the score in the hash table does provide an extremely simple implementation that would work on most engines, which is a good thing.

[michiguel]

It is more uses than that. For instance, I could want to search only two or three moves to choose from them, or exclude all the moves that lead to particular type of game (it could be more than one). I cannot do that with usermove.

Sure you can: 3x usermove, and 3x undo...

That is not the same. With include move1 move2, you do iterative deepening ply by ply with only move1 and move2. What you say does not resemble that process: it is manual and move2 will be searched with different windows and not iteratively.

The 'setscore' command you proposed easy enough for a programmer to understand, but I'm not so sure about expecting the average Winboard user to specify the depth and score parameters. (Maybe that isn't what you intended.) In any case, my preference would be for Winboard to just support the 'searchmoves' command.

The winboard protocol has a command 'pause' that will tell the engine to freeze the search to be continued later. I implemented that in Gaviota because it is extremely useful. Unfortunately, it is not implemented in the GUI..

Indeed, pause could be implemented too. But to really make it work would be a bit of a hassle. You would have to save the entire hash table, for instance. But setscore would have other uses, and pause only one. You can do everything with it you can do with searchmoves, and more.

Just for the record, implementing pause is extremely easy. It needs a mutex (or semaphore) that is examined every ~1024 nodes. The main thread when it receives pause, locks the mutex, and when it receives resume unlocks it. It just needs to record how much time was "paused" to discount it from the clock so nps will look ok.

It is not clear to me what the advantage is to specify that a subsequent position should not be reached compared to telling not to search a particular move (which will reach that position). If I want to exclude a move, why not telling the engine directly rather than using an indirect approach? Many engines are UCI/Winboard. They could apply the UCI procedure in a very quickly rather than implementing a complete different approach.

Not searching a position and not searching a move is equivalent. That is not the difference between searchmoves and setscore. That equivalence is also reflected in the syntax. In both cases they contain a move, not a position. The difference is that with setscore you can exclude the move conditionally: upto a certain depth. And the method of storing the score in the hash table does provide an extremely simple implementation that would work on most engines, which is a good thing.

I just do not see why this is simpler than saying "do not search this move", which is the intention of the user.

Miguel