Polyglot and playing by nodes

[H.G.Muller]

Michel:

There was a request on TalkChess to allow UCI engines to play in WinBoard node-based time controls (sort of). Now the only WB node-based TC for which there is a strict UCI equivalent is of course st T in combination with nps R, which translates to UCI go nodes R*T. But for the other WB time controls it is of course possible to do some kind of a make-shift implementation to translate them to a fixed number of nodes per move on a move-by-move basis.

I made such a patch on the 1.4.38x source I had still lying around, and it seems to work satisfactorily. In fact so much, that there now is a request to put this patch in the main line. What do you think?

http://www.talkchess.com/forum/viewtopic.php?t=29927

[Michel]

Do you have an actual patch which I can apply?

[H.G.Muller]

I can sent you the xboard2uci.c of Polyglot 1.4.38x if you want. But it is twelve steppings behind your most recent one. Fortunately the patch is very localized.

[Michel]

I can sent you the xboard2uci.c of Polyglot 1.4.38x if you want. But it is twelve steppings behind your most recent one. Fortunately the patch is very localized.

I was suggesting just sending me a diff between your old xboard2uci.c and new one (diff -u oldfile newfile) . Then I can directly apply that patch to my version of xboard2uci.c without having to do any error prone copying.

[H.G.Muller]

Hmm, yes. That would indeed be a very good idea. If I only had kept the old file...

[Michel]

Well in that case send me the new file.

EDIT Don't bother. I can download it from your website.

[Michel]

I haven't looked at your file yet but I am a bit confused about the meaning of the nps command.

As I understand it the engine cannot use directly the time given to it by the GUI.

Example

Suppose we play 2 moves in 2 seconds (repeated) (i.e. level 2 0:2 0) . The engine's intrinsic nps is 100000 but we set nps=1000.

To start the engine gets 2 second from the GUI (time=200). So it computes that it has 2/2=1 second for this move.
It searches 1000 nodes and returns after 0.01 second.

For the second move the engine gets now 1.99 seconds (time=199) from the GUI. So it now searches another 1990 nodes.
So in total it has searched 2990 nodes instead of 2000 as was the intention.

So the engine should only use the information given to it in the level command. Is this correct?
An alternative would be for the engine to sleep until its time quotum is used up.

[H.G.Muller]

No, the engine should use the WB time command. I should just use the given nps factor to convert it to the number of nodes left on its "clock".

I am sorry I messed up by not saving the old xboard2uci.c so that I cannot make a proper diff. But it was really a very simple patch. Most o it I already posted on CCC, and concerned the sending of the UCI go command:

Code: Select all

         engine_send_queue(Engine,"go");

         if (XB->time_limit) {

            // fixed time per move

      if(node_rate > 0)
            engine_send_queue(Engine," nodes %.0f",XB->time_max*(double)node_rate);
      else
            engine_send_queue(Engine," movetime %.0f",XB->time_max*1000.0);

         } else {

            // time controls

      if(node_rate > 0) {
      double time;
      move_nb = 40;
                if (XB->mps != 0) move_nb = XB->mps - (Uci->board->move_nb % XB->mps);
      time = XB->my_time / move_nb;
      if(XB->inc != 0) time += XB->inc;
      if(time > XB->my_time) time = XB->my_time;
               engine_send_queue(Engine," nodes %.0f",time*node_rate);
      } else {
            if (colour_is_white(Uci->board->turn)) {
               engine_send_queue(Engine," wtime %.0f btime %.0f",XB->my_time*1000.0,XB->opp_time*1000.0);
            } else {
               engine_send_queue(Engine," wtime %.0f btime %.0f",XB->opp_time*1000.0,XB->my_time*1000.0);
            }

            if (XB->inc != 0.0) engine_send_queue(Engine," winc %.0f binc %.0f",XB->inc*1000.0,XB->inc*1000.0);

            if (XB->mps != 0) {

               move_nb = XB->mps - (Uci->board->move_nb % XB->mps);
               ASSERT(move_nb>=1&&move_nb<=XB->mps);

               engine_send_queue(Engine," movestogo %d",move_nb);
            }
      }
         }

         if (XB->depth_limit) engine_send_queue(Engine," depth %d",XB->depth_max);


The only other places where I made a change are one added feature command in send_xboard_options():

Code: Select all

    gui_send(GUI,"feature usermove=1");
    gui_send(GUI,"feature nps=1");
    if (XB->has_feature_memory){


plus the delaration of a global variable node_rate:

Code: Select all

// constants

static const bool UseDebug = FALSE;
static const bool DelayPong = FALSE;
int node_rate = -1;


setting it in the new recognition of the WB nps command:

Code: Select all

      } else if (match(string,"nps *")) {

         // fake WB play-by-nodes mode
         node_rate = atoi(Star[0]);

      } else if (match(string,"playother")) {


and clearing it on a WB new command in xboard2uci_gui_step():

Code: Select all

         XB->new_hack = TRUE;
         XB->result = FALSE;

         XB->depth_limit = FALSE;
         node_rate = -1;


That is really all. Looking at this it seems you might prefer to declare the node_rate as a member of the XB structure.

I put the assumed number of remaining moves in a sudden-death game to 40 here; perhaps it would be better to change that to 30. In the worst cae that would lead to allocating more time to early moves than to later moves, which usually is not so bad for playing strength anyway. And there might be engines that implement 'go nodes' in such a way that they do not always use that exact number of nodes, but actually stop early, so that their average time use is below the limit we give anyway. So it seems good to set a generous limit. An alternative might be to multiply time by 1.2 just before testing if it exceeds XB->my_time, to bias time allocation towards early moves.

[Michel]

No, the engine should use the WB time command. I should just use the given nps factor to convert it to the number of nodes left on its "clock".

You didn't comment on my example....

It seems just converting the WB time command would make the engine search many more nodes than intended.

[H.G.Muller]

Perhaps I do not understand the question, then.

The engine needs the WB time command to know how much time is left on its clock, so it can convert it to how much nodes are left on its clock. The Polyglot patch does this, because XB->my_time is (presumably) updated by the WB time command. It then uses the number of moves left to calculate from this how many nodes it must search _for this move_, which is the only thing a UCI engine can understand. A native WinBoard egine supportin nps would do this calculation itself, of course, in the same way as it would normally process the time given in the WB time command to arrive at a (target) time for the next move.

[Michel]

Can you please explain what's wrong with my example.... That would presumably make things clear for me.

[H.G.Muller]

Example

Suppose we play 2 moves in 2 seconds (repeated) (i.e. level 2 0:2 0) . The engine's nps is 100000 and we set nps=1000.

To start the engine gets 2 second from the GUI (time=200). So it computes that it has 2/2=1 second for this move.
It searches 1000 nodes and returns after 0.01 second.

For the second move the engine gets now 1.99 seconds (time=199) from the GUI. So it now searches another 1990 nodes.
So in total it has searched 2990 nodes instead of 2000 as was the intention.

Ah, OK, sorry. I missed the example entirely, because I skipped the quote box assuming that you quoted a previous post...

The point is that the GUI also knows the engine is playing in nps mode, so that it should pass "virtual time" to the engine, in stead of real time. If it reports having searched 999 nodes in its Thinking Output, and WB knows that it is playing at nps 1000, it decrements that engine's clock by 999/1000 = 1 sec. So on the next move it will send time 100, and not time 199.

[Michel]

The point is that the GUI also knows that it should pass virtual time to the engine, in stead of real time. If it reports having searched 999 nodes in its Thinking Output, and WB knows that it is playing at nps 1000, it decrements that engine's clock by 999/1000 = 1 sec. So on the next move it will send time 100, and not time 199.

Ok this information was missing from the protocol description. I guess that would work well.

The nps command requires WB to have unlimited trust in the engine.... I would like to see a match between Crafty and Rybka at 80knps

[H.G.Muller]

The nps command requires WB to have unlimited trust in the engine.... I would like to see a match between Crafty and Rybka at 80knps

Indeed, there is no way to avoid cheating with this. But for this reason the nps rates can be set for the two engines seperately. Someone using this mode will find out quickly enough which engines will use more than their fair share of time when running in this mode. (Presumably they would benchmark the true nps first, and use that value.) So rel cheating, rather than just (intentional) miscalibration, would really require subtlety, making the engine behave differently during the benchmark than during a real match.

I guess I should mention something about using the reported nodes for decrementing the clock. I guess I left that out because it is not really a protocol matter how the GUI implemets this, but it is important to stress that the engine shuould report the same number of nodes in its thinking output as on what it based its timing decisions.

[Michel]

I guess I should mention something about using the reported nodes for decrementing the clock. I guess I left that out because it is not really a protocol matter how the GUI implemets this, but it is important to stress that the engine shuould report the same number of nodes in its thinking output as on what it based its timing decisions.

Well up to now providing thinking output was optional. This protocol addition makes it non optional. So it should definitely be mentioned.

BTW what about pondering....

[H.G.Muller]

I guess this mode is not very useful with ponder on. Also because in pracice it might often have the character of a time-odds game in terms of real time. Time odss also becomes a bit meaningless with ponder on.

[matematiko]

Please ignore this post and continue on, I just want to let you guys know that is very fascinating seeing you talking, sharing ideas and suggestions in a language (even thou is in english) that is well above my understanding. Undoubtely, you guys had made the polyglot-winboard (in alphabetical order) partnership a better experience. Keep up the good team work.

Regards,

[Roger Brown]

Please ignore this post and continue on, I just want to let you guys know that is very fascinating seeing you talking, sharing ideas and suggestions in a language (even thou is in english) that is well above my understanding. Undoubtely, you guys had made the polyglot-winboard (in alphabetical order) partnership a better experience. Keep up the good team work.

Regards,

Hello Matematiko,

Rest assured, even the native English speakers among us cannot follow everything they say but I find the interplay between them fascinating and I look forward to reading what the two of them are up to next.

Definitely one of the must read threads.

Later.

[Michel]

Ok I copied the nps code by HGM to my files. I hope I didn't make any mistakes....

This is now version 1.4.51b....

http://alpha.uhasselt.be/Research/Algeb ... t-release/

I tested it with glaurung and it seemed to do the right thing (toga and fruit do not seem to support the
nodes command).

One strange thing I noticed: I was using the command

xboard -fcp glaurung -fUCI -firstNPS 8000

This worked fine for the engine (glaurung). However xboard seemed to completely mess up the time control
for the human player (me). Apparently the node accounting was also applied to the human.

[H.G.Muller]

I will have a look at this.