Appeal to authors: Standardize kibitz format

[hgm]

No it isn't the same. Chessbase has done more than one version of this, creating _new_ PGN tags for eval, etc. Which makes a PGN very difficult to read.

Well, its the same as WinBoard/XBoard would store it in the PGN. Putting anything extra in the PGN besides the moves make it less readable, but a format of {-1.27/15} is at lest bearable.

But my comment came from ICC where I used to not label the values in kibitzes and got continual questions.

You would be free to write the explanatory words behind it, e.g.

-1.27/15 (score/nodes)

You could even kibitz

-1.27/15 (That means Crafty thinks, after searching 15 ply deep, that black is 1.27 pawn ahead. A ply is a half move.)

That should suppress most questions. But it would leave the possibility open for engine authors that do not care about questions to cram as much info as possible in the message in a compact way. I don't like to force anyone to use very verbose kibitz output.

But there is no standard for PGN that I am aware of, with respect to how program information is encapsulated, other than it has to be done inside comments.

It sounds like you are trying to add a new engine-to-GUI command, which would be fine by me. Just tell me how to format it and I'll add that quickly. I don't like the idea of your trying to parse the "tellics kibitz <etc>" string stuff since I have changed mine more than once as I add things that provide new information that observers might find interesting, such as book moves, and such.

No, this will not be a new engine->GUI command. It is purely enhanced ICS-client functionality of WinBoard/XBoard, and has nothing to do with the engine (if any) loaded in XBoard. I just want WinBoard to understand what the opponent is kibitzing to it, so it can put the scores in the eval graph, and put them in the PGN.

You can still put anything you want in the kibitz. All I ask is that you put in score and depth in a form that your opponent's XBoard can recognize, once per move. You can even do that in combination with as many kibitz messages per move in whatever format you want, as long as XBoard won't recognize that format.

In fact, when you use XBoard to play in zippy mode, all you have to do is run with the option -autoKibitz, and your XBoard will add this once-a-move kibitz message in exactly the right format for the opponent's XBoard to understand. But not everyone is using XBoard, and rely on their own engine to generate all kibitz messages. I would like the feature to also work when playing against those opponents.

[bob]

No it isn't the same. Chessbase has done more than one version of this, creating _new_ PGN tags for eval, etc. Which makes a PGN very difficult to read.

Well, its the same as WinBoard/XBoard would store it in the PGN. Putting anything extra in the PGN besides the moves make it less readable, but a format of {-1.27/15} is at lest bearable.

Absolutely no argument from me, there. ChessBase makes PGN effectively unreadable for me as a human. A %tag for each kind of info recorded, is tough to parse for a human.

But my comment came from ICC where I used to not label the values in kibitzes and got continual questions.

You would be free to write the explanatory words behind it, e.g.

-1.27/15 (score/nodes)

You could even kibitz

-1.27/15 (That means Crafty thinks, after searching 15 ply deep, that black is 1.27 pawn ahead. A ply is a half move.)

That should suppress most questions. But it would leave the possibility open for engine authors that do not care about questions to cram as much info as possible in the message in a compact way. I don't like to force anyone to use very verbose kibitz output.

But there is no standard for PGN that I am aware of, with respect to how program information is encapsulated, other than it has to be done inside comments.

It sounds like you are trying to add a new engine-to-GUI command, which would be fine by me. Just tell me how to format it and I'll add that quickly. I don't like the idea of your trying to parse the "tellics kibitz <etc>" string stuff since I have changed mine more than once as I add things that provide new information that observers might find interesting, such as book moves, and such.

No, this will not be a new engine->GUI command. It is purely enhanced ICS-client functionality of WinBoard/XBoard, and has nothing to do with the engine (if any) loaded in XBoard. I just want WinBoard to understand what the opponent is kibitzing to it, so it can put the scores in the eval graph, and put them in the PGN.

You can still put anything you want in the kibitz. All I ask is that you put in score and depth in a form that your opponent's XBoard can recognize, once per move. You can even do that in combination with as many kibitz messages per move in whatever format you want, as long as XBoard won't recognize that format.

In fact, when you use XBoard to play in zippy mode, all you have to do is run with the option -autoKibitz, and your XBoard will add this once-a-move kibitz message in exactly the right format for the opponent's XBoard to understand. But not everyone is using XBoard, and rely on their own engine to generate all kibitz messages. I would like the feature to also work when playing against those opponents.

My problem with this is that "tellics kibitz" has been around for almost 15 years now. Crafty has lots of things it can kibitz, from "Mate in 13 moves" to book move information that doesn't even have a score or depth associated with it.

I'd prefer something like "info score/depth/whatever" so that the engine is clearly sending that specific information that you could define to include whatever you want. Changing "kibitz" is a pretty significant change inside Crafty beause it has a ton of options to kibitz different kinds of information, from mate announcements, to various levels of search output (from simple score at end to score/depth/time/pv each time it changes (including fail highs, researching information, etc.)

You already need changes from most programs, apparently, to capture this. Might as well plan ahead and allow future expansion. Isn't there a "stat01" engine-to-xboard command already where xboard can send a "." to get the info whenever it wants???

[hgm]

In principle it is not a bad idea to start kibitz outut that is specifically meant to convey the depth and score that belonged to the played move, and thus should go in the PGN, with some unig\que, recognizable string. Even if XBoard could be made smart enough to interpret any kibitz message and extract score ad depth from it, it would not be a good thing to do so. Many engines kibitz several iterations, or even ponder info, all in the same format, and it would be almost impossible to figure out with kibitz message belongs to the move that was played.

I don't want to restrict the engines in any way in what they can kibitz, or how often they can do it. But I would like there to be a single, easily identifiable kibitz message with the required info. Every kibitz message that would not match this pattern will simply be ignored by XBoard. (if it has a large umeric content it will appear in the engine-output window, that is all.)

Using "info" as a recognizable start pattern might be a bad idea, because it is too obvious, and some engines might already use it with kibitz messages with a different format or with different info. So if there would have to be a specific start pattern, it should preferably be one that is less likely to be independently picked. E.g. "!!! ".

But in fact a "%+.2f/%d" pattern would not do so bad. It is not very likely to be used, and if it is used to start the kibitz, it is extremely likely to represent score/depth. But such "accdental triggers" might indeed be undesirable, as they enhance the probability to mistakenly recognize the message from a wrong iteration.

Shall we settle for "!!! score/depth whatever PV=pv_moves", kibitzed immediately after the move, then? (The "PV=" will not currently be recognized by XBoard, but this is to make it easy when we migt want to do that in the future.)

[bob]

In principle it is not a bad idea to start kibitz outut that is specifically meant to convey the depth and score that belonged to the played move, and thus should go in the PGN, with some unig\que, recognizable string. Even if XBoard could be made smart enough to interpret any kibitz message and extract score ad depth from it, it would not be a good thing to do so. Many engines kibitz several iterations, or even ponder info, all in the same format, and it would be almost impossible to figure out with kibitz message belongs to the move that was played.

I don't want to restrict the engines in any way in what they can kibitz, or how often they can do it. But I would like there to be a single, easily identifiable kibitz message with the required info. Every kibitz message that would not match this pattern will simply be ignored by XBoard. (if it has a large umeric content it will appear in the engine-output window, that is all.)

Using "info" as a recognizable start pattern might be a bad idea, because it is too obvious, and some engines might already use it with kibitz messages with a different format or with different info. So if there would have to be a specific start pattern, it should preferably be one that is less likely to be independently picked. E.g. "!!! ".

But in fact a "%+.2f/%d" pattern would not do so bad. It is not very likely to be used, and if it is used to start the kibitz, it is extremely likely to represent score/depth. But such "accdental triggers" might indeed be undesirable, as they enhance the probability to mistakenly recognize the message from a wrong iteration.

Shall we settle for "!!! score/depth whatever PV=pv_moves", kibitzed immediately after the move, then? (The "PV=" will not currently be recognized by XBoard, but this is to make it easy when we migt want to do that in the future.)

Easy enough for me. However, the .2f might cause issues since some use millipawns rather than centipawns? While we are at it, what about checkmate?

Crafty has always used "MatNN/-MatNN" type scores. And at present, the output code translates mate scores from x.xx to the above automatically. Would be nice to have a uniform way of indicating checkmate as well, since that is non-uniform as well...

[hgm]

The problem is that engine mate scores are not standardized in WB protcol. When XBoard has to produce the Kibitz message all by itself from the thinking output, (under the -autoKibitz option) it has no way to recognize mate scores and translate them to a mate-in-so-many.

milliPawn precision would not be a problem.As long as there are at least two digits behind the decimal point, even if the score happens to be an integer, to make it unambiguous to the reader which is score and which is depth.

[bob]

The problem is that engine mate scores are not standardized in WB protcol. When XBoard has to produce the Kibitz message all by itself from the thinking output, (under the -autoKibitz option) it has no way to recognize mate scores and translate them to a mate-in-so-many.

milliPawn precision would not be a problem.As long as there are at least two digits behind the decimal point, even if the score happens to be an integer, to make it unambiguous to the reader which is score and which is depth.

It would not hurt to standardize scoring. For example, many use EGTBs and that forces you to use a standard mate score at that point, although you can then translate it to whatever you want. Also a score of 1.21 is not clear as not every program uses 1.00 as a pawn either...

[sje]

Crafty has always used "MatNN/-MatNN" type scores. And at present, the output code translates mate scores from x.xx to the above automatically. Would be nice to have a uniform way of indicating checkmate as well, since that is non-uniform as well...

Symbolic has always used MateInN/LoseInN where LoseIn0 means "I am checkmated". (Actually, a LoseIn0 score is output as "Checkmated".) For an absolute even score, Symbolic outputs "Even".

For internal use, there are a few more special scores like PosInf, NegInf, and Broken. Non-special scores are kept in micropawn units and are expressed externally as decimal pawns, usually with three digits past the radix point.

The Banjo score object will follow this convention where the originating program can use any precision it likes for expressing decimal pawns. It will be up to each individual client to present the score data according to user preference.

A similar flexible precision will be supported for elapsed time objects, although the server itself will round values to the nearest microsecond. The usual ICS time resolution of a whole second is near useless for engine/engine bullet games, but a microsecond resolution will support extremely fast time controls with plenty of room to spare.

[hgm]

It would not hurt to standardize scoring. For example, many use EGTBs and that forces you to use a standard mate score at that point, although you can then translate it to whatever you want. Also a score of 1.21 is not clear as not every program uses 1.00 as a pawn either...

It is not easy to standardize scoring in the engine thinking output without breaking compatibility of the engine with existing interfaced. WB protocol specifies the score fild as to be numeric, and most engines use a %d format to read it. Send something like M6, and the entire line is not even recognized as thinking output, and sore+PV ae discarded as well.

In Joker I work around this problem by sending a numeric prefix "1000." in stead of "M". So mate in 6 will show up as 1000.06 in an interface not aware of this convention, but could be translated to "M6" on printing by an interface that is. Disadvantage is that the scores, when interpreted as numeric values rather than digit strings, evolve in counter-intuitive way, decreasing if you approach the mate. In practice, however, this disadvantage is far outweighed by not having to subtract to see the mating distance, as in case of 99.94.

Of course the 1000.06 has nothing to do with the score the engine uses internally; it is converted on printing.