A few questions about CECP

[mar]

Hi (hgm?),
I have a few questions about CECP:

1) clocks:
I would rather rely on time/otim instead of handling the clocks myself. Of course I can simply readjust when i get time/otim, but that's extra work for me. With other words: is it safe to rely on time/otim?
2) pondering:
When can I expect to get easy/hard? If the engine is already pondering and receives easy, should it abort the search? And if it receives hard, should it start pondering immediately if there's a ponder move?
Also, on ponderhit, can the engine rely on current clocks set by time/otim (same as 1)? The question is, assuming that the GUI doesn't know whether the engine is pondering and on what move it's pondering, is it safe to assume that time/otim sent before move made by the user/opponent?
3) level and st, how am I supposed to orthogonally combine these commands? I mean should I assume that when I don't get level after new that it's undefined? Also what if I receive go and neither level/st is issued?
4) result
The specs say it's mandatory to send result when the engine thinks/knows the game is over. May I ask why? Is it safe to rely on the GUI to adjudicate the game instead?
5) hash size
What is the preferred way to do that? Using an option? Or using memory command? The problem with memory command is that some memory is already used by code+data itself so it's not quite possible to reliably divide memory among tables.
6) thinking output
What is the standard way to report fails at root? I tried to append + or - to depth but this seems to confuse WinBoard/xboard. I can either ignore that completely or append that to PV. How to report selective depth? Can I simply use D/SD? Also how does the GUI parse score in thinking output? Can I send a custom string or does it rely on an integer? I'm talking about mate scores. Or use a defacto standard used by Polyglot and some engines that 9999 cp is mate in one and -9999 is mated in one (plies)?
Also should the score be from engine's point of view or always from white's POV? Or is it engine-specific? The GUI only cares about the result, but what about adjudication?
7) edit mode
From what I understand, the engine is supposed to clear ep square and automatically set castling rights when exiting edit mode. What is not clear to me is how is it supposed to work in FRC mode? Always assing castling rights to outermost rooks? Also I've read in the specs that Chessbase
added some new commands (what the hell is "fritz" command? but unfortunately i get 404 when I click the link. Of course I would rather rely on setboard, can I assume that when I set feature setboard=1 and it gets accepted by the GUI that it won't use edit mode?
8) k-best mode
What is expected of the engine to support k-best mode?
9) ICS
Is the engine supposed to do something special when in ics mode?
10) up to date specs?
Are there up to date specs to be found somewhere? I think hgm added excludemoves and other stuff recently.
What I've found is this: http://www.open-aurec.com/wbforum/WinBo ... -intf.html

I have to say that I'm starting to like CECP. The engine gets more freedom (and more responsibility). Plus I absolutely love the low verbosity of the protocol.

Thanks

Martin

[hgm]

1) clocks:
I think all existing GUIs send time and otim before they set an engine thinking. The protocol does not strictly require this, but it would seem extremely poor GUI design to miss the obvious opportunity to synchronize the clocks. In practice you will time how long the engine is thinking, to know when to stop. So it will not be a big deal to subtract that time from your engine's timeLeft variable just before you submit your move, just in case. Most engines ignore otim, so there is also no need to measure that yourself.
2) pondering:
You can receive hard / easy at any time; the GUI will send it immediately when the user alters the ponder state. And indeed, if the user asks to switch ponder off, the engine should stop pondering. If the user switches it on again, immediately starting pondering would be a good idea.
I think (1) also answers the rest of this question.
3) level and st
You will either receive level or st, there is no combining. (That is only for depth, sd.) I don't think 'new' should reset the TC in anyway (although it resets depth).
4) result
GUIs will usually adjudicate on checkmate and stalemate, but might not adjudicate on rep-draw or 50-move. WinBoard would not even adjudicate checkmate if legality testing is off.
5) hash size
Use the memory command. Only count large buffers (hash table, EGTB cache, bitbases). Code definitely should not be counted. Engines are free to decide how they want to use the memory.
6) thinking output
Do not append anything to depth, as Win/XBoard will identify you as GNU Chess, and expect you to also have other non-compliancies. Always start with 4 integers. There is no standard for fail low, but I would recommend writing ++ or -- after the PV (which should be just 1 or 2 moves in that case). The PV is officially free format, but recent WB versions try to parse it with the PGN parser for PV-walking or conversion to SAN. So if you want to report additional stuff there, do it in a way that the PGN parser won't choke on. Like putting it in comment braces {}. WinBoard uses sscanf(input, "%d%c%d%d%d",...) == 5 to recognize thinking input, and the %c had better be a space.
Scores should be from engine POV, and only few engines are non-compliant in this respect (for which the GUI has corrective options). No standard for mating score could so far be agreed on, but if I would ever implement one in WinBoard I would use 100000+N for mate in N full moves, like Joker does (and adapt Polyglot accordingly). Basically the 1 + leading zeros should be read as 'mate' in this encoding, making it bearable in GUIs that do not have special support for it. (I hate subtracting...)
7) edit mode
Do not use it! Basically edit mode is deprecated. Support the 'setboard' command, which transfers FEN.
8) k-best mode
WinBoard recognizes an engine-defined option MultiPV (like feature option="MultiPV -spin 1 1 10") and will allow a user to adjust it by clicking in the Engine Output window. It would still appear in the Engine Settings window, which it would no matter what name you gave it, or when you used other systems to regulate the number of PVs. (e.g. Fairy-Max uses a centi-Pawn threshold for multi-PV).
Send each PV only once; do not send the same PV again and again as in UCI, just because you found others. WinBoard will sort them by score.
9) ICS
There is no need to do anything special, but youcould, as there is a command 'tellics' that allows you to directly communicate with the ICS.
10) up to date specs?
Tricky question. I would have to check if I documented the exclude-moves commands anywhere. The WB version that does support them is not officially released yet. I will get back to this.

[Edit]
OK, it seems I did update the engine-intf.html in the source repository, but it does not seem to be posted anywhere on line as a separate file. You can get it directly from my on-line git repository through gitweb, and requesting it 'raw' will actually make the browser display it!

http://hgm.nubati.net/cgi-bin/gitweb.cg ... e12ad25d70

[mar]

Thanks for the prompt answer!
Got it, two last questions remain:
How to send different PVs in multipv mode?. I guess the GUI simply expects that whatever PV is sent for the same depth is multipv, then sorts them (up to k) in descending order by score.
And the last question is what to sent when pondering? Let's say the engine just played e4 and assumes the opponent replies with e5.
I assume the PV should be formatted as (e5) Nf3 ..., with additional info in {} after the PV. Am I supposed to send move numbers as well or just move list?
Thanks again.

[jdart]

The Winboard forum might be a better place to post these questions.

That said, I know a few answers:

I would rather rely on time/otim instead of handling the clocks myself. Of course I can simply readjust when i get time/otim, but that's extra work for me. With other words: is it safe to rely on time/otim?

Not sure what you are asking. There are basically 3 time control modes: fixed time per move, fixed time per n moves (like 40 moves/40 minutes) and incremental time control (time + increment). There's also a fixed depth mode. To calculate proper time usage you generally have to know what mode you are in and what time is left. Note though UCI does not ever tell you how many moves remain until time control so if you want not use that info you can ignore it (but it can be helpful to have it).

2) pondering:
When can I expect to get easy/hard? If the engine is already pondering and receives easy, should it abort the search? And if it receives hard, should it start pondering immediately if there's a ponder move?
Also, on ponderhit, can the engine rely on current clocks set by time/otim (same as 1)? The question is, assuming that the GUI doesn't know whether the engine is pondering and on what move it's pondering, is it safe to assume that time/otim sent before move made by the user/opponent?

You should get easy/hard at the start of a game just after "new".

I do not think the behavior is defined if you get easy or hard during a game.

Winboard always sends time/otim just before "usermove" so you will have that info when the opponent moves and before you are pondering or deciding how much more to search in case of a ponder hit.

Winboard debug mode can be very helpful in elucidating details of the protocol.

level and st

I think these are mutually exclusive.

The specs say it's mandatory to send result when the engine thinks/knows the game is over. May I ask why? Is it safe to rely on the GUI to adjudicate the game instead?

Winboard may or not adjudicate games. This is an option. If it doesn't it will rely on the engine to tell it when the game is over.

Also the result command is used to resign: the engine can decide to do this.

hash size

The memory command is the standard way to do this. I think it is ok to approximately follow the specified memory size.

thinking output

Scores are integers and are in centipawns.

I think scores are supposed by default to be from the engine's POV. If your engine reports from the White POV then the -first(second)ScoreIsAbs true|false" option can be used to tell Winboard this.

--Jon

[mar]

Thanks Jon,

The Winboard forum might be a better place to post these questions.

That said, I know a few answers:

Not sure what you are asking. There are basically 3 time control modes: fixed time per move, fixed time per n moves (like 40 moves/40 minutes) and incremental time control (time + increment). There's also a fixed depth mode. To calculate proper time usage you generally have to know what mode you are in and what time is left. Note though UCI does not ever tell you how many moves remain until time control so if you want not use that info you can ignore it (but it can be helpful to have it).

I already got the answers I needed so I think it won't be necessary.

What I meant is that in theory the GUI could only send time/otim at the beginning of the game, but now I see it's safe to assume I get time/otim before each move/go.
AFAIK UCI uses movestogo so the engine knows how many moves remain to next TC.

Winboard debug mode can be very helpful in elucidating details of the protocol.

Yes I guess that's the best way to debug engine<->GUI communication.

Also the result command is used to resign: the engine can decide to do this.

I though that's what resign is for. But ok I will send result anyway, just in case...

[hgm]

How to send different PVs in multipv mode?. I guess the GUI simply expects that whatever PV is sent for the same depth is multipv, then sorts them (up to k) in descending order by score.

Indeed, that is how it does it. Also in single PV mode you sometimes get several PVs, butthen the one with the higher score automatically comes in last. For multi-PV mode I let the GUI sort, to provide the engine with the freedom to find the PVs in whatever order it likes.

And the last question is what to sent when pondering? Let's say the engine just played e4 and assumes the opponent replies with e5.
I assume the PV should be formatted as (e5) Nf3 ..., with additional info in {} after the PV. Am I supposed to send move numbers as well or just move list?

The specs prescribe starting with the ponder move in parentheses. This unfortunately deviates from standard PGN, so the PV parsing makes an exception when it encounters parentheses in the beginning.

Whether you put move numbers or not is upto you. WinBoard's PGN parser would just skip over those.

For visibility it would be better to locate additional info near the beginning of the PV, as the end will often be out of view. (Better not put it before the ponder move, though, as I am not 100% sure whether this would interfere with the special treatment of the parentheses.) You can put comments anywhere in the PV, but better not chain multiple comments between the same two moves. I am thinking of defining a spec for how to include commonly reported stuff that is not in the normal thinking output as a comment. (Like TB hits, selective depth, hash use.)

[mar]

The specs prescribe starting with the ponder move in parentheses. This unfortunately deviates from standard PGN, so the PV parsing makes an exception when it encounters parentheses in the beginning.

Whether you put move numbers or not is upto you. WinBoard's PGN parser would just skip over those.

For visibility it would be better to locate additional info near the beginning of the PV, as the end will often be out of view. (Better not put it before the ponder move, though, as I am not 100% sure whether this would interfere with the special treatment of the parentheses.) You can put comments anywhere in the PV, but better not chain multiple comments between the same two moves. I am thinking of defining a spec for how to include commonly reported stuff that is not in the normal thinking output as a comment. (Like TB hits, selective depth, hash use.)

Ok, thanks.
So I will put extra info at the beginning/after ponder move and in {}.
As for other commonly reported stuff, what about parsing these inside parentheses? Something like #b:l #s:n #t:n #h:n (with b being bounds at root)? It would not interfere with the PGN parser and xboard would silently remove these from the comments and display them in some pretty format.