uci ponder issue

[Desperado]

[d]5k2/1p3pb1/p2p4/5p1P/b1P5/P5r1/3q4/5R1K b - - 0 36

well, i was just in mood to watch my engine playing some bullet games.

When the above position occured, Nemo(black pieces) already looped over all iterations (in ponder-mode)
It is forced to send a move when all iterations are done, which was
of course ignored by the gui, and so Nemo(with 30s, very painful) lost on time because
ponderhit jumps into no-where so to say. (dead lock...).

Or in other words, ponder-search was finished before Sjeng finished the
search process for Kg1-Kh1, so before the move was played.

i am not sure how to handle that case at first glance, when pondering.
Of course i can reserve the best move and switch to some kind of idle-loop, until the ponderhit command is received or whatever.

now a simple question, what are your engines doing in that case ?

Michael

[hgm]

The protocol as I understand it requires you to wait for stop or ponderhitbefore you can send bestmove. An engine should never spontaneously send a move while pondering.

No one 'forces' you to send a move when you finished all iterations during ponder. In fact, no one forces you to ponder. It would even be illegal to ponder unless the engine was asked to do so. So you must know how to handle the case where the engne is idle, waiting for input.

[Desperado]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

[mcostalba]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

In SF we simply call std::getline() and block there waiting for user input before to send best move.

Be warned to do not return while pondering also in case of book move:

Code: Select all

  // Look for a book move
  if &#40;Options&#91;"OwnBook"&#93;.value<bool>())
  &#123;
      if &#40;Options&#91;"Book File"&#93;.value<std&#58;&#58;string>() != book.name&#40;))
          book.open&#40;Options&#91;"Book File"&#93;.value<std&#58;&#58;string>());

      Move bookMove = book.get_move&#40;pos, Options&#91;"Best Book Move"&#93;.value<bool>());
      if &#40;bookMove != MOVE_NONE&#41;
      &#123;
          if &#40;Limits.ponder&#41;
              wait_for_stop_or_ponderhit&#40;);

          cout << "bestmove " << bookMove << endl;
          return !QuitRequest;
      &#125;
  &#125;

[Edmund]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

http://www.distributed.net/Main_Page/en

I hope this made you happy now ...

[Desperado]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

In SF we simply call std::getline() and block there waiting for user input before to send best move.

Be warned to do not return while pondering also in case of book move:

Code: Select all

  // Look for a book move
  if &#40;Options&#91;"OwnBook"&#93;.value<bool>())
  &#123;
      if &#40;Options&#91;"Book File"&#93;.value<std&#58;&#58;string>() != book.name&#40;))
          book.open&#40;Options&#91;"Book File"&#93;.value<std&#58;&#58;string>());

      Move bookMove = book.get_move&#40;pos, Options&#91;"Best Book Move"&#93;.value<bool>());
      if &#40;bookMove != MOVE_NONE&#41;
      &#123;
          if &#40;Limits.ponder&#41;
              wait_for_stop_or_ponderhit&#40;);

          cout << "bestmove " << bookMove << endl;
          return !QuitRequest;
      &#125;
  &#125;

Indeed, simply checking the comInput for stop/ponderhit/quit seems to be enough.
(after a short look into your sources. I should read your sources more often i guess ).

i ll keep in mind your hint with the book moves,
but currently i dont have any kind of own book implementation.

cheers, Michael

btw, a good idea could be to tune eval params while being in idle-state

[Desperado]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

http://www.distributed.net/Main_Page/en

I hope this made you happy now ...

i think i prefer this one http://www.distributed.net/Main_Page/zh-hans

[Desperado]

True.

No way out, when ponder search is finished (by reaching maxPly) i have
to burn some cycles for nothing, simply waiting for stop or ponderhit.
Otherwise the communication will break, like it did.

but if anyone has an idea, if there can be done sth. useful , i would
be happy about it.

Michael

http://www.distributed.net/Main_Page/en

I hope this made you happy now ...

i think i prefer this one http://www.distributed.net/Main_Page/zh-hans

oh, i missed the point! But now i got it. So yes, that makes me and my little engine happy...

Michael

[Onno Garms]

In SF we simply call std::getline() and block there waiting for user input before to send best move.

Fortunately you do wait_for_stop_or_ponderhit() (which calls getline and evaluates the result against "stop", "ponderhit", and "quit") don't you? If you just called getline, you would incorrectly send bestmove on "isready" or "somegarbage".

[mcostalba]

In SF we simply call std::getline() and block there waiting for user input before to send best move.

Fortunately you do wait_for_stop_or_ponderhit() (which calls getline and evaluates the result against "stop", "ponderhit", and "quit") don't you? If you just called getline, you would incorrectly send bestmove on "isready" or "somegarbage".

Yes, this is correct, I should have better explained.