Asymetric Node/move in winboard for UCI engines

[FrancoisK]

Hello,

I am trying to play games in winboard with asymetric fixed node number per moves between a winboard and a UCI engine
I managed to make winboard send the right command "sn 250000" to the winboard engine (BugChess2 actually), but i don't know how to make winboard send the right thing to polyglot so that the UCI engine receives a "go nodes 100000" command. Is it possible ?
I am using the last "winboard goldpack".

Thanks for any help or moral support

François

[hgm]

The recommended way to play with fixed number of nodes per move in WinBoard is to send the nps command to define translation from time to nodes (e.g. nps 250), and then fixed time per move (e.g. st 1) which translates to the number of nodes you wanted.

UCI engines can handle the equivalent to WinBoard nps+st time control, as the go nodes command, but have no equivalen to the nps+classical or nps+incemental controls. In principle Polyglot could fake that it understands nps (feature nps=1), and use the strict translation under st time control, and a make-shift translation that it cooks up itself by just dividing time left by moves left and translate that time to nodes according to the nps setting.

I don't know any Polyglot version that supports this, though. Perhaps we should suggest it to Michel? I could of course put it in as a further patch on the Polyglot 1.4.38 code I patched before; it does not seem too difficult. The UCI engines would be slightly disadvantaged by this, though, because they are really playing an st-type tme control (the only one they know as nodes), while the WinBoard opponent might allocate its nodes more economically, like it normally allocates time.

How do UCI engines implement the go nodes command anyway? Do they always search for exactly that number of nodes, or would they refreain from starting an iteration that they know to be pointless (e.g. because they already used up 80% of the time, ad know they could not even finish the search of the first move in the next iteration)? On engines that do it the latter way, Polyglot could give them a little bit of extra nodes to what they nominally have. Perhaps such an "overshoot" factor should be made an adjustable Polyglot option.

[hgm]

You could try this Polyglot:

http://home.hccnet.nl/h.g.muller/polyglot.zip

Note that it is completely untested. I just put in code to send feature nps=1 at startup, and recognize the nps R command and remember R (and reset it on new. On the UCI side, whenever a go command is sent, I suppress all time qualifiers when R was given, and convert the time left to a number of nodes, appended as a nodes N qualifier, based on the TC used and moves left.

[FrancoisK]

Great, thanks a lot !
I will try this as soon as i can, probably today.

[FrancoisK]

I have juste tried it, polyglot does send a "go nodes X", but it seems that X is wrong. As it is shown in the following log extract, i am playing in 40 moves / 10 seconds and NPS 900000 Nodes/Sec, but the first command sent by polyglot is "go nodes 290322581" which would correspond to 290322581/900000 = 322 seconds !

...
773924.437 GUI->Adapter: ics -
773924.437 GUI->Adapter: level 40 0:10 0
773924.437 GUI->Adapter: nps 900000
773924.437 GUI->Adapter: post
773924.437 GUI->Adapter: hard
773924.437 POLYGLOT WAIT
773924.437 GUI->Adapter: easy
...
773927.109 GUI->Adapter: time 1000
773927.109 GUI->Adapter: otim 979
...
773927.109 GUI->Adapter: go
773927.109 POLYGLOT THINK
773927.109 POLYGLOT START SEARCH
773927.109 POLYGLOT FEN r2qk2r/pp1n1ppp/2p2n2/2b1p2b/4P3/5NPP/PPPNQPB1/R1B2RK1 b kq - 2 10
773927.109 Adapter->Engine: position startpos moves g2g3 d7d5 f1g2 g8f6 g1f3 c7c6 e1g1 c8g4 h2h3 g4h5 d2d3 b8d7 b1d2 e7e5 e2e4 d5e4 d3e4 f8c5 d1e2
773927.109 Adapter->Engine: go nodes 290322581
...

[hgm]

Seems I did not correctly remember my own protocol extensions...

I thought that the nps command specified knps, but it is indeed plain nps, (as the name suggests...). So multiplying the specified value by 1000 was not a good idea!

The version that is at the link now should have this fixed.

Even divided by 1000 the value (0.322 sec) is a bit fishy. I would have expected 0.250 sec. The code I modified in Polyglot is this, and it seems to me it should arrive at 0.250:

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&#40;move_nb>=1&&move_nb<=XB->mps&#41;;

               engine_send_queue&#40;Engine," movestogo %d",move_nb&#41;;
            &#125;
	   &#125;
         &#125;

         if &#40;XB->depth_limit&#41; engine_send_queue&#40;Engine," depth %d",XB->depth_max&#41;;

         if &#40;State->state == PONDER&#41; engine_send_queue&#40;Engine," ponder");

         engine_send&#40;Engine,""); // newline

[FrancoisK]

Thanks, that is working perfectly !

I can explain the fishy value : i have fixed starting positions defined as moves. In the position of our example, there were 9 book moves, which leaves 31 book moves to be played in 10 seconds, and we fall back on our feet

It is true the UCI engine is a little disadvantaged, but i don't mind as i only want fixed level opponents for my gauntlets. Moreover, I have implemented the "go nodes" command in the UCI engine (talking about fish, it is Strelka ) so that it tries to save nodes.

Do you think it will be possible to integrate you patch in the main development branch ?

[Daniel Mehrmann]

Hello,

please tell (explain) me the sense behind the idea XXXX nodes in XXX moves/time ???

What do you wanna test ??? (If you know how a engine works in search)

Best,
Daniel

[hgm]

Do you think it will be possible to integrate you patch in the main development branch ?

I will ask Michel. I don expect any problems there.

Daniel:

The idea is to use node count as a measure of the engine's resource consumption rather than wall-clock time, because
1) For very fast games communicatation and scheduling delays make wall-clock time a very inaccurate measure for what the engine was allowed to do.
2) It makes the test result insensitive to other work-load on the computer.
3) results are more deterministic, because timing jitter is eliminated (with single CPU).

To achieve this, the WB nps command defines an equivalence between time and nodes. So all the engine has to do to implement this is keep a node counter, and let its clock() routine return this node counter converted to time, to know the 'virtual' time it has been thinking. In all other respects it can handle its time management as usual, allocating extra time on fail lows, thinking longer when just out-of-book, etc.

[Daniel Mehrmann]

As expected you try to do a race between a mouse, elephant and a tiger just for example.

Your idea doesn't work at all because every programmer handle search stuff different. It's starts already with "how to enter a node" or better "how to count nodes".

There is no modell for all possibilities. Furthermore results might be handle different und of course search which isn't finished , we might not use all stages, gives not useable results.

You can't define it inside a protocol as well, because you'll never know every possible idea and implementation of each programmer.

However, its funny - Yes ! But you can't use it for serious testing. Its just more a running gag for the users out there.

Best,
Daniel

ps: Each reliable engine-developer will tell you the same.