WinBoard protocol extension proposal: exclude moves

[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

[hgm]

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.

Who says it is manual? The user does not even have to be aware of what goes on between GUI and engine.

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.

Does not sound like this would work very well when you switch off the computer...

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

But I also do not see why it would be more difficult to skip searching the move than to assign it a phoney score. In code, one would require:

Code: Select all

if(banned[currentMove] != ENABLED)
  continue;
else {
  MakeMove();
  score = -Search();
  UnMake();
}

the other is

Code: Select all

if(banned[currentMove] != ENABLED)
  score = banned[currentMove];
else {
  MakeMove();
  score = -Search();
  UnMake();
}

I don't think there will be manyengine authors that say: "Oh no, I won't consider implementing B, that is faaaar too much work. If it would have been only A, then I would have considered it".

[marcelk]

When analyzing a position with an engine, it can sometimes be convenient to forbid certain moves in the root.

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

setscore DEPTH SCORE MOVE


Feedback is welcome.

I have an 'exclude <move> ...' command in my engine that just does that.
I use it for opening book analyses.

Why make a more involved interface if all you need is exclude moves. Leave it up to the implementor to decide how to deal with it.

Put in another way: what is the use case for using 'setscore' in another way than proposed? I can imagine a 'setscore <FEN> <score>' for bookbuilding, but not 'setscore <move>'.

Just my thought.

[hgm]

The idea was that when you have been making an analysis tree, and stored it, you could reload it at a later time, and feed the previous results to the engine, to make it continue where you left off.

[jwes]

The idea was that when you have been making an analysis tree, and stored it, you could reload it at a later time, and feed the previous results to the engine, to make it continue where you left off.

I am going to try to add this to crafty and scid. It is not only for continuing analysis, but also when analyzing different branches the computer doesn't have to reanalyze the first branch after finishing the second branch.

[marcelk]

The idea was that when you have been making an analysis tree, and stored it, you could reload it at a later time, and feed the previous results to the engine, to make it continue where you left off.

I understand, but then why opt for 'setscore <move> <score> <depth>' instead of 'setscore <position> <score> <depth>'? With the first you limit yourself to positions one ply from the root position. With the latter you can preload any arbitrary prior analyses into the engine.

[hgm]

This is certainly a good alternative.

[michiguel]

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.

Who says it is manual? The user does not even have to be aware of what goes on between GUI and engine.

Even if you automatize this, my other points are still valid. It is not the same and less efficient.

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.

Does not sound like this would work very well when you switch off the computer...

Off course, I was just pointing out that is not difficult to do it.
On the other hand, the only efficient method to really continue from where you left, if you switch off the computer is to both save the hash table and the stack (which can only be done if you do an iterative search).

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

But I also do not see why it would be more difficult to skip searching the move than to assign it a phoney score. In code, one would require:

Code: Select all

if(banned[currentMove] != ENABLED)
  continue;
else {
  MakeMove();
  score = -Search();
  UnMake();
}

the other is

Code: Select all

if(banned[currentMove] != ENABLED)
  score = banned[currentMove];
else {
  MakeMove();
  score = -Search();
  UnMake();
}

I don't think there will be manyengine authors that say: "Oh no, I won't consider implementing B, that is faaaar too much work. If it would have been only A, then I would have considered it".

Sure, but if the methods are equally easy to implement, why doing the indirect way?

Miguel