some UCI protocol issues/questions

Discussion of chess software programming and technical issues.

Moderator: Ras

Dann Corbit
Posts: 12792
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: some UCI protocol issues/questions --> a defect

Post by Dann Corbit »

Michel wrote:
Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.

--Jon
Sorry there is a misunderstanding. Sending a "bestmove" is infinite analysis mode is a protocol violation. As far as I know Fruit handles this correctly (i.e. it does NOT send a bestmove).

Even if the engine detects a mate in one it should not return from the search but instead go into some kind of delay loop until "stop" is received.
Something for both Winboard and UCI protocols that is missing:
Engine says:
DONE: Bxc4 Nxc4#

What I mean by this is that if the engine has proven to its own liking that there is no better move possible, it should inform the GUI.

What is an engine doing slogging along in an 80 ply search when it found a mate in 4?

It is a very, very irritating waste of time when an engine has solved a position and yet (because there is not any clear "I'm DONE now" signal, it must search again and again, proving to itself what it already knows.
Michel
Posts: 2292
Joined: Mon Sep 29, 2008 1:50 am

Re: some UCI protocol issues/questions --> a defect

Post by Michel »

What is an engine doing slogging along in an 80 ply search when it found a mate in 4?
This has nothing to do with the protocol. If the engine thinks it has proven that there is a mate in 4 and there is no shorter mate then it can just wait for "stop" and consume no CPU time at all.

But with today's reductions it is hard for an engine to know if it has really found the shortest mate. That's why most engines keep searching. But even then the pv will show the mate and the user can just stop the search.
Michel
Posts: 2292
Joined: Mon Sep 29, 2008 1:50 am

Re: some UCI protocol issues/questions

Post by Michel »

jdart wrote:But then after stop - it should do nothing?
It should just return "bestmove".

stop should _always_ be followed by bestmove (if the engine has been given a search command). Even if the bestmove is useless (e.g. after a ponder miss).

This predictability ensures that UCI does not need a ping equivalent to avoid race conditions (isready is not to avoid race conditions).
UncombedCoconut
Posts: 319
Joined: Fri Dec 18, 2009 11:40 am
Location: Naperville, IL

Re: some UCI protocol issues/questions

Post by UncombedCoconut »

jdart wrote:But then after stop - it should do nothing?
After stop the engine should send a bestmove. It just mustn't stop by itself. See for instance this thread.
I'm not really sure what you should do if a GUI asks you to search in a position where you're mated (check- or stale- :)) Stockfish treats it as a no-op. The only alternative I can think of is sending pv and bestmove as "0000" (which is UCI for a null move).
Michel
Posts: 2292
Joined: Mon Sep 29, 2008 1:50 am

Re: some UCI protocol issues/questions

Post by Michel »

UncombedCoconut wrote:
jdart wrote:But then after stop - it should do nothing?
After stop the engine should send a bestmove. It just mustn't stop by itself. See for instance this thread.
I'm not really sure what you should do if a GUI asks you to search in a position where you're mated (check- or stale- :)) Stockfish treats it as a no-op. The only alternative I can think of is sending pv and bestmove as "0000" (which is UCI for a null move).
This is unfortunately not specified in the protocol. But it is implied I think that the GUI will not ask the engine to search in a position where there is no legal move (this is meaningless anyway).
UncombedCoconut
Posts: 319
Joined: Fri Dec 18, 2009 11:40 am
Location: Naperville, IL

Re: some UCI protocol issues/questions

Post by UncombedCoconut »

I've read enough threads here to doubt anything is so stupid that no GUI will do it. :)
User avatar
michiguel
Posts: 6401
Joined: Thu Mar 09, 2006 8:30 pm
Location: Chicago, Illinois, USA

Re: some UCI protocol issues/questions --> a defect

Post by michiguel »

Dann Corbit wrote:
Michel wrote:
Then not just Fruit, but a lot of Fruit variants, are broken in analysis mode. Unless I misread the source.

--Jon
Sorry there is a misunderstanding. Sending a "bestmove" is infinite analysis mode is a protocol violation. As far as I know Fruit handles this correctly (i.e. it does NOT send a bestmove).

Even if the engine detects a mate in one it should not return from the search but instead go into some kind of delay loop until "stop" is received.
Something for both Winboard and UCI protocols that is missing:
Engine says:
DONE: Bxc4 Nxc4#

What I mean by this is that if the engine has proven to its own liking that there is no better move possible, it should inform the GUI.

What is an engine doing slogging along in an 80 ply search when it found a mate in 4?

It is a very, very irritating waste of time when an engine has solved a position and yet (because there is not any clear "I'm DONE now" signal, it must search again and again, proving to itself what it already knows.
That will make the protocol easier to implement for the engine.

In Gaviota, I had to add a mutex to lock the search until stop is received. In this way, Gaviota does not waste useless CPU cycles. But of course, this adds some unneeded complexity.

Miguel
Dann Corbit
Posts: 12792
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: some UCI protocol issues/questions --> a defect

Post by Dann Corbit »

Michel wrote:
What is an engine doing slogging along in an 80 ply search when it found a mate in 4?
This has nothing to do with the protocol. If the engine thinks it has proven that there is a mate in 4 and there is no shorter mate then it can just wait for "stop" and consume no CPU time at all.

But with today's reductions it is hard for an engine to know if it has really found the shortest mate. That's why most engines keep searching. But even then the pv will show the mate and the user can just stop the search.
Nope. It is a clear protocol defect because the engine and GUI sit for half an hour waiting for the analysis to complete, but it has already completed.
jdart
Posts: 4406
Joined: Fri Mar 10, 2006 5:23 am
Location: http://www.arasanchess.org

Re: some UCI protocol issues/questions --> a defect

Post by jdart »

I don't think this is such a big deal.

But if (as appears) the protocol doesn't really allow changing the # of variations shown w/o restarting the search, that is a problem. Changing the # is a very useful feature. Rybka supports this as far as I can tell. Plus as noted ChessBase etc. assume this is possible.

UCI has a lot of other deficiencies. It doesn't signal the engine that the game is over, or what the result was (very useful if the engine has learning features). Because it only sends the move list to the engine, it is also very hard for the engine to keep track of where it is in the game. So the basic assumption is the GUI keeps all the state and the engine, very little.
Dann Corbit
Posts: 12792
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: some UCI protocol issues/questions --> a defect

Post by Dann Corbit »

jdart wrote:I don't think this is such a big deal.

But if (as appears) the protocol doesn't really allow changing the # of variations shown w/o restarting the search, that is a problem. Changing the # is a very useful feature. Rybka supports this as far as I can tell. Plus as noted ChessBase etc. assume this is possible.

UCI has a lot of other deficiencies. It doesn't signal the engine that the game is over, or what the result was (very useful if the engine has learning features). Because it only sends the move list to the engine, it is also very hard for the engine to keep track of where it is in the game. So the basic assumption is the GUI keeps all the state and the engine, very little.
Like many other things, it is a big deal for me and for almost nobody else on the planet.

I often will take a list of 150 positions, and let a very strong engine analyze at (for instance) 1/2 hour per position over the weekend. It will often be the case that ten hours or so is completely wasted because of sitting there doing nothing for 20 of the positions.

It is especially true when analyzing a large segment of endgame positions.

It probably bothers nobody else at all, but it bugs me to no end.