score from White's perspective, or engine's perspective?

[sje]

From stomping thru 4.x assembly language, to the best of my recollection it was done exactly the same way all of us have been doing. Internally, +=good for program, and in their case, that was the way they displayed their data as well.

Well, at least the write-up for Chess 4.x described its evaluation function f() as being a measure of "how well White is doing". And I seem to recall that at least one term of the program's evaluation produced asymmetric results based on color. This was certainly true of MacHack; I have Greenblatt's report in front of me and can verify.

For what it's worth, Chess 0.5 does all of its positional evaluation White POV. There's a single sign application that appears at the end of the evaluator:

Code: Select all

INTV := XTMV[JNTM] *(MBVAL[JNTK]+INTV);

and this changes the result (INTV) to Active Color POV.

I don't recall the details, but I believe that there were a number of early microcomputer programs that did Black POV, as they were unable to play with the White pieces!

[hgm]

Robert,

I think you are saying that annotated games should show the score from White's point of view.

But others suggest that WinBoard should display scores from the engine's point of view, meaning the score from the engine's point of view is reported to Winboard.

Those two statements are contradictory...

How the engine represents it internally, how it reports it to the GUI and how the GUI represents it to the user are three different and independent matters.

If some people prefer annotated games to have the score from white'perspective, there should simply be an option in the GUI that allows them to do that. Perhaps this same option should affect how the score is displayed in the main window. Although scores are not really part of the PGN standard (they are inserted as comments), it would be nice if there was some standard convention that would tell the reader how the black score is reported. E.g. use depth/score for own POV, and depth\score for white POV. If people would agree on a standard for this, I can add it to WinBoard / xboard (both the option, and the format to save in the PGN).

How the engine reports to the GUI is not only a matter of convenience, but affects how the GUI might adjudicate games. WinBoard already has options to correct protocol-violating engines, but every engine-specific option you have to supply is always a pain, so it is much better to maintain a standard.

[Marc Lacrosse]

Although scores are not really part of the PGN standard (they are inserted as comments), it would be nice if there was some standard convention that would tell the reader how the black score is reported. E.g. use depth/score for own POV, and depth\score for white POV. If people would agree on a standard for this, I can add it to WinBoard / xboard (both the option, and the format to save in the PGN).

Scores _are_ part of the PGN standard.

In chapter 16.2.5.6 of PGN standard v1994.03.12 there is the following description (part of the EPD spec) :

"The opcode "ce" indicates the evaluation of the indicated position in centipawn units. It takes a single operand, an optionally signed integer that gives an evaluation of the position from the viewpoint of the active player ."


Although I agree that "absolute" values are easier to read and have become a de facto standard, maybe we should take into account that quite a few old programs follow the old way.

There should also be a new rewritten version of the PGN spec document.

Another point : the UCI protocol also defines the score as "cp <x> the score from the engine's point of view in centipawns."

So If we decide that scores should be communicated in the absolute way (positive is good for white) we would in fact go against both the PGN and UCI specs ...


Marc

[hgm]

What you are referring to is not in the definition of PGN bt in the definition of EPD. PGN obtains no opcode, and WinBoard (nor any other GUI I know of) puts the score in the PGN in centiPawns.

UCI is a standard for communication between engines and Polyglot, which has nothing to do with PGN in the first place.

[Marc Lacrosse]

What you are referring to is not in the definition of PGN bt in the definition of EPD. PGN obtains no opcode, and WinBoard (nor any other GUI I know of) puts the score in the PGN in centiPawns.

Both winboard I and II protocols as written by Tim Mann do not include anything on the precise topic of how should evaluation be wroten (absolute : white better is always positive, or relative : white better is positive when white is to move, negative when black is to move).

So it is not uninteresting to have a look at what other standards say :

- EPD definition is part of the PGN definition document.
This is the only place in this document where the way to describe a position evaluation is mentioned.
It clearly recommends relative signs.

- UCI is much more than a standard of communication between engines and Polyglot. It is also simply the standard through which the majority of engines communicate with the majority of GUIs. UCI protocol explicitly recommends relative scores.

So If you decide to define that _your_ modified winboard requires and outputs evaluations the absolute way (white better is positive), how will you deal with epd's passed through copy/paste from engines and/or GUI's who do follow the EPDspec and/or the UCI one. And those who copy EPDs from your winboard to anything else will have to edit the sign of the scores before pasting them into any PGN/EPD or UCI compliant application ...

My point is that PGN/EPD specification, UCI protocol and WB protocol need to have the same interpretation of signed numerical evaluations unless you accept that everybody will need a database of what is issued by whom anytime evaluation data are exchanged .

If you wish that we go for the more logical "absolute" evaluations (which i do also prefer) then there must be a consensus for changing all three protocols alltogether simultaneously (WB, UCI, PGN-EPD) ...

... and everybody has to accept that the majority of older applications will produce strange output everytime a signed evaluation is concerned.

Marc

[sje]

Isn't also the case that every dedicated chess computer model with score display capability presented scores from Machine POV instead of White POV?

That's the way that the relatively recent Novag Citrine does it and I think all prior Novag units did the same.

[bob]

From stomping thru 4.x assembly language, to the best of my recollection it was done exactly the same way all of us have been doing. Internally, +=good for program, and in their case, that was the way they displayed their data as well.

Well, at least the write-up for Chess 4.x described its evaluation function f() as being a measure of "how well White is doing". And I seem to recall that at least one term of the program's evaluation produced asymmetric results based on color. This was certainly true of MacHack; I have Greenblatt's report in front of me and can verify.

That is a different issue and chess 4.x did exactly what I do in Crafty, which is the eval computes things as +=good for white, -=good for black, but then if it is btm, negates the score it returns so that the actual search is always +=good for program. When any value is output, I always convert +=good for program to +=good for white for clarity.

For what it's worth, Chess 0.5 does all of its positional evaluation White POV. There's a single sign application that appears at the end of the evaluator:

Code: Select all

INTV := XTMV[JNTM] *(MBVAL[JNTK]+INTV);

and this changes the result (INTV) to Active Color POV.

That is what I do. But internally in the search, it is always +=good for program. Then along came negamax and made it +=good for side on move at a particular ply.

I don't recall the details, but I believe that there were a number of early microcomputer programs that did Black POV, as they were unable to play with the White pieces!

[bob]

Isn't also the case that every dedicated chess computer model with score display capability presented scores from Machine POV instead of White POV?

That's the way that the relatively recent Novag Citrine does it and I think all prior Novag units did the same.

As I said, most do that. But it isn't the clearest. Just like all chess diagrams show white at the bottom and black at the top for clarity. In a middlegame position you can tell which side is white's first rank. But in endgames you can not... Unless it is always "down".

[xsadar]

Robert,

I think you are saying that annotated games should show the score from White's point of view.

But others suggest that WinBoard should display scores from the engine's point of view, meaning the score from the engine's point of view is reported to Winboard.

Those two statements are contradictory...

How the engine represents it internally, how it reports it to the GUI and how the GUI represents it to the user are three different and independent matters.

If some people prefer annotated games to have the score from white'perspective, there should simply be an option in the GUI that allows them to do that. Perhaps this same option should affect how the score is displayed in the main window. Although scores are not really part of the PGN standard (they are inserted as comments), it would be nice if there was some standard convention that would tell the reader how the black score is reported. E.g. use depth/score for own POV, and depth\score for white POV. If people would agree on a standard for this, I can add it to WinBoard / xboard (both the option, and the format to save in the PGN).

How the engine reports to the GUI is not only a matter of convenience, but affects how the GUI might adjudicate games. WinBoard already has options to correct protocol-violating engines, but every engine-specific option you have to supply is always a pain, so it is much better to maintain a standard.

Personally, I think it would be better if the gui displays the score from white's point of view, but the most important thing is that it be consistent (which it isn't now). However, the way engines report scores to the gui does not need to be consistent as long as the gui knows how it's being reported. What you could do is make a feature called either 'whitepov' or 'ownpov' and recommend that engines explicitly set or clear this feature depending on what the engine does. Then, if the POV is not explicitly specified, just assume one or the other based on what's most common for engines that exist right now (which I would guess is own POV, which I believe is what polyglot does as well).

[AndrewShort]

My original post was wrong, that isn't what I do. Don't know what I was thinking....

Here is what I do:

My eval computes things as +=good for black, -=good for white, but then if it is white to move, negates the score it returns so that the actual search is always +=good for program (if you reverse all the blacks and whites in the above sentence, it makes no difference whatsoever). Since negamax is always from the pov of side to move, and since the program is always the side to move before search is called, the final answer is always from the engine's pov (+=good for engine).

When any value is output, I always show +=good for program (I don't convert it to be from White's pov).

But this discussion is making me rethink the output - that I should convert the outputted score so it's always from White's pov...