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

[AndrewShort]

Internally, my engine's search returns a score from Black's perspective, meaning if the final backed up score is positive, Black is winning. [That was arbitrary - I could have chosen White just as easily.]

When I display the score in my own user interface, I negate the score if the engine is White, so that the score is always from the engine's perspective, meaning if the engine is ahead (as White or Black), the score is positive.

Is that what is conventional? Obviously it's a matter of taste, but I'm curious what the convention is. I know there was a post on this a while back (by prof. Hyatt), but I couldn't find it...

[hgm]

Although there are some engines that sin against the rule, WinBoard engines should print the score from their own perspective (as part of the thinking Output lines). I.e. positive means they are winning.

Even more engines faul up when they are pondering. Also there, they should use positive score when they are winning.

[Harald]

Internally, my engine's search returns a score from Black's perspective, meaning if the final backed up score is positive, Black is winning. [That was arbitrary - I could have chosen White just as easily.]

When I display the score in my own user interface, I negate the score if the engine is White, so that the score is always from the engine's perspective, meaning if the engine is ahead (as White or Black), the score is positive.

Is that what is conventional? Obviously it's a matter of taste, but I'm curious what the convention is. I know there was a post on this a while back (by prof. Hyatt), but I couldn't find it...

I believe many engines do it this way:
- In the deeper evaluation functions positive is good for white and negative is good for black.
- Whether you use an if .. else ... or some arrays[color] is up to you.
- In the highest evaluation function and in the interface to the search
positive is good for the side to move and negative is good for the opponent.
- That goes up the search with the negamax, negascout(), PVS or
alphabeta algorithms. Typically you see:
score = - search(-beta, -alpha, depth-1).
- Output to the GUI is done according to the protocol.

+Harald-

[sje]

In the Early Days long before the Internet, the literature -- and the few programs written -- consistently scored moves, positions, and searches from the White point of view. Authors who were active from Back Then or whose early influence was from literature of those days may unsurprisingly adopt White POV scoring.

But starting from the late 1970's, the literature started to change and algorithms were presented with a color neutral perspective. I believe that the idea of presenting scores form the viewpoint of the active color was easier to understand and slightly simpler to program. So more recent efforts (or at least efforts by more recent programmers) tend to the Active Color POV.

All of my code has been Active Color POV, except for opening book formation. That's because all positions are normalized for White To Move to enable extra hits for color reversed opening positions.

[bob]

Internally, my engine's search returns a score from Black's perspective, meaning if the final backed up score is positive, Black is winning. [That was arbitrary - I could have chosen White just as easily.]

When I display the score in my own user interface, I negate the score if the engine is White, so that the score is always from the engine's perspective, meaning if the engine is ahead (as White or Black), the score is positive.

Is that what is conventional? Obviously it's a matter of taste, but I'm curious what the convention is. I know there was a post on this a while back (by prof. Hyatt), but I couldn't find it...

I have been using +=good for white for 10+ years now. It is easy to understand and avoids confusion in chess events where you kibitz analysis. +=good for black makes no sense at all to me. You typically see glyphs like +- meaning white is winning, or +/= meaning white has an advantage or -/= meaning black has an advantage. So most human chess players think + is good for white, and most chess books give numerical scores in that way...

[bob]

In the Early Days long before the Internet, the literature -- and the few programs written -- consistently scored moves, positions, and searches from the White point of view. Authors who were active from Back Then or whose early influence was from literature of those days may unsurprisingly adopt White POV scoring.

But starting from the late 1970's, the literature started to change and algorithms were presented with a color neutral perspective. I believe that the idea of presenting scores form the viewpoint of the active color was easier to understand and slightly simpler to program. So more recent efforts (or at least efforts by more recent programmers) tend to the Active Color POV.

All of my code has been Active Color POV, except for opening book formation. That's because all positions are normalized for White To Move to enable extra hits for color reversed opening positions.

This makes annotated games impossible to read, when all the scores are + and -, but you have to stop to see who is moving. More naturally, +=good for white makes reading annotated games (by computers) much easier to read and follow as you can see at a glance which side is winning without any POV issues at all.

BTW, I don't recall any white POV programs from the early days. Mine. Belle's. Chess 4.x/etc were all self-POV programs in their output. And the micros of the early 90's were as well. Crafty was the first program I ever saw that used WPOV scores and it was roundly criticized for years until many others decided to follow for the same reasons I had used...

[AndrewShort]

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...

[sje]

BTW, I don't recall any white POV programs from the early days. Mine. Belle's. Chess 4.x/etc were all self-POV programs in their output. And the micros of the early 90's were as well. Crafty was the first program I ever saw that used WPOV scores and it was roundly criticized for years until many others decided to follow for the same reasons I had used...

I am referring to the internal POV in use. Usually that is what is exported, although it can be flipped on output under certain circumstances if that's what the author wants.

Turochamp was internal White POV, as was MacHack and Chess 3.x/4.x. I'm fairly sure that the Bernstein, Kotov, and Tech programs were also all internal White POV.

Symbolic and the CIL Toolkit use Active Color POV. To me, this is the only way of doing internal POV that makes sense and is directly compatible with nearly all the algorithmic descriptions published in the last quarter century. Note that at the root level, internal Active Color POV becomes Machine POV on output.

[bob]

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...

Not necessarily. Use winboard, put it in "analysis mode" and see how confusing that is. Start off, score is positive, make a move, now score is negative, make a move, now score is positive. From trying both, I easily prefer +=good for white in all cases, it makes the scores easy to interpret. Given a FEN, I don't have to figure out who is winning, if I see a + score, it is white, no matter who is to move first...

I don't see why winboard would even _care_ about the score. It just displays it in an engine output window. What would it actually do with the score in the first place, other than to display it...

[bob]

BTW, I don't recall any white POV programs from the early days. Mine. Belle's. Chess 4.x/etc were all self-POV programs in their output. And the micros of the early 90's were as well. Crafty was the first program I ever saw that used WPOV scores and it was roundly criticized for years until many others decided to follow for the same reasons I had used...

I am referring to the internal POV in use. Usually that is what is exported, although it can be flipped on output under certain circumstances if that's what the author wants.

Turochamp was internal White POV, as was MacHack and Chess 3.x/4.x. I'm fairly sure that the Bernstein, Kotov, and Tech programs were also all internal White POV.

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. They had no way to do recursion, and used the classic loop instead which makes WPOV very difficult.I have a ton of output from their program, as we had a copy to play with on some of Harry's Cray's out at Livermore back then.. I had not seen a program display scores from WPOV prior to Crafty in 1995. And WPOV internally is a real mess as it makes it comparing alpha/beta backward when the program plays black.

But for display, I think WPOV makes for clarity. But it is a personal decision. I had this discussion 12-13 years ago when I first started to display all output from the WPOV...

Symbolic and the CIL Toolkit use Active Color POV. To me, this is the only way of doing internal POV that makes sense and is directly compatible with nearly all the algorithmic descriptions published in the last quarter century. Note that at the root level, internal Active Color POV becomes Machine POV on output.

There I agree. But internal wasn't the discussion I was involved in. It was how to display scores externally, where WPOV is (IMHO) much clearer. I noticed that as I have Crafty analysis going on during WC type games, I no longer get questions about "is + good for white or good for the side Crafty is searching?"