WinBoard protocol extension proposal: exclude moves

[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]

[quote="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.).
[quote]

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

[JVMerlino]

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.

When Johan and I were working on how to implement pause in the Chessmaster GUI, it was very helpful that The King cleared its hash tables with every move. So our solution wasn't a "pause", but actually a stop/restart.

Wherever The King was during its search, if the user hit "pause", The King would stop and clear everything. Then when the user "unpaused", the GUI would rewind the clock to the start of The King's move and The King would start thinking again from the beginning. The result was identical, because The King's hash tables would be cleared either way.

We also had to think of our typical user -- somebody who was a very casual player and not a knowledgeable computer chess user like the people here. The main reason people would pause their game against a computer personality was so they could do some other work and then come back. Other people complained that their computers were very slow when they tried to play a game AND do some work at the same time. As I said, these were not very knowledgeable people.

Just a story to tell -- not very useful for this discussion....

jm