[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
uci ponder issue
Moderators: hgm, Rebel, chrisw
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: uci ponder issue
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.
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.
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: uci ponder issue
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
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
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: uci ponder issue
In SF we simply call std::getline() and block there waiting for user input before to send best move.Desperado wrote: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
Be warned to do not return while pondering also in case of book move:
Code: Select all
// Look for a book move
if (Options["OwnBook"].value<bool>())
{
if (Options["Book File"].value<std::string>() != book.name())
book.open(Options["Book File"].value<std::string>());
Move bookMove = book.get_move(pos, Options["Best Book Move"].value<bool>());
if (bookMove != MOVE_NONE)
{
if (Limits.ponder)
wait_for_stop_or_ponderhit();
cout << "bestmove " << bookMove << endl;
return !QuitRequest;
}
}
-
- Posts: 670
- Joined: Mon Dec 03, 2007 3:01 pm
- Location: Barcelona, Spain
Re: uci ponder issue
http://www.distributed.net/Main_Page/enDesperado wrote: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
I hope this made you happy now ...
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: uci ponder issue
Indeed, simply checking the comInput for stop/ponderhit/quit seems to be enough.mcostalba wrote:In SF we simply call std::getline() and block there waiting for user input before to send best move.Desperado wrote: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
Be warned to do not return while pondering also in case of book move:
Code: Select all
// Look for a book move if (Options["OwnBook"].value<bool>()) { if (Options["Book File"].value<std::string>() != book.name()) book.open(Options["Book File"].value<std::string>()); Move bookMove = book.get_move(pos, Options["Best Book Move"].value<bool>()); if (bookMove != MOVE_NONE) { if (Limits.ponder) wait_for_stop_or_ponderhit(); cout << "bestmove " << bookMove << endl; return !QuitRequest; } }
(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
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: uci ponder issue
i think i prefer this one http://www.distributed.net/Main_Page/zh-hansEdmund wrote:http://www.distributed.net/Main_Page/enDesperado wrote: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
I hope this made you happy now ...
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: uci ponder issue
oh, i missed the point! But now i got it. So yes, that makes me and my little engine happy...Desperado wrote:i think i prefer this one http://www.distributed.net/Main_Page/zh-hansEdmund wrote:http://www.distributed.net/Main_Page/enDesperado wrote: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
I hope this made you happy now ...
Michael
-
- Posts: 224
- Joined: Mon Mar 12, 2007 7:31 pm
- Location: Bonn, Germany
Re: uci ponder issue
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 wrote: In SF we simply call std::getline() and block there waiting for user input before to send best move.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: uci ponder issue
Yes, this is correct, I should have better explained.Onno Garms wrote: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 wrote: In SF we simply call std::getline() and block there waiting for user input before to send best move.