Most wanted missing features for a chess GUI

[Edmund]

Something I have not read before would be to allow for per engine score and score-variance calibration.

The most streight forward one would be to allow for an engine like SF to set: f(score) = score /2

This can be easily done, of course, although I wonder how useful it is. (I can devide by 2 mentally quite easily.) It can potentially cause a lot of confusion, when comparing scores of Stockfish with scores posted by other people, using other calibration.

It seems that you want to cure a defect in the engine here by patching the GUI. I am not too keen on that. There is a well-defined standard for reporting engine scores (centi-Pawns), and if engines deviate from it, it should be considered an engine bug, and fixed in the engine. Trying to normalize it in the GUI sort of sanctions everyone to just do as he pleases, making an arbitrary mess of it, dumping the problem in the lap of the user. Not a good thing, and not worth facilitating, IMO.

Maybe one could make it more elaborate and allow for a multivariate regression equation (where the gui exposes a series of easily accessible parameters):
f(score, #blocked_pawns, material_white, material_black, etc.) = ...

next one could differentiate and add different functions for win, draw probability. furthermore one could add a function also taking depth, nodes searched and statistics about previous PVs to predict the score variability.

Eventually engine users would independently look for well predicting parameters running regressions over their game logs. These paramters can be exchanged online for the whole comunity to benefit.

I see the following gains:
a) we get more information out than just some arbitrary centipawn score
b) one can compare different engines output better
c) the GUI can correct for engine differences and engine specific score informations e.g. the point of view of the scores, Depth to conversion, different types of draw, etc.

The system would be evolutionary with gradually improving predictors as more people get involved.

A lot of this sounds like science fiction to me. Can such a multivariate regression work at all? How many games would have to be played with the same engine to learn this information? How can a GUI ever derive a renormalization of engine scores when it doesn't know what the scores would have to be? Or draw conclusions from the win rate if it doesn't know the strength of the opponent? I cannot imagine anything practical that would do this. But perhaps you have thought this out more than I have.

Centipawns is by no means a well-defined standard. When talking about the value of the pawn, is it a pawn on the second rank? On which file? Whats the value of an additional pawn? Etc. The standard doesn’t give any requirements to this “centipawn”-score, other than that the order of values is preserved (a better move according to the engine should get a higher score). As such I think it is the default of the standard and not the GUI or Engine. Given that there is no standardization to be expected on the protocol side I think the GUI could step in instead as an additional feature provided to the users.

I would have seen this as a two-step approach. First the form is specified and the coefficients get estimated. And second the GUI just takes as an option for each engine an equation that tells it how to transform the score exposing certain parameters.
The first step could happen independently of the GUI. One takes a large set of games with engine evaluations, using a tool one collects per position data and finally runs a regression on game outcome (or better expected outcome given the elo difference).

[hgm]

Centipawns is by no means a well-defined standard. When talking about the value of the pawn, is it a pawn on the second rank? On which file? Whats the value of an additional pawn? Etc.

I thought it is almost universally accepted that this refers to the 'classical piece value' scale, 1, 3, 3, 5, 9 (or the Kaufman values, which would not make that much of a difference). Real problems only occur in Chess variants quite different from FIDE (e.g. in Shatranj, where a Pawn promotes to the worthless Ferz, or in Xiangqi, where it even captures only straight forward and doesn't really promote at all, would you still want P=100, and consequently R=800 or 1000?)

The standard doesn’t give any requirements to this “centipawn”-score, other than that the order of values is preserved (a better move according to the engine should get a higher score).

Not sure which specs you are talking about then. I have never seen the phrase "you can use any monotonically increasing function you like to express the attractiveness of a position". The CECP specs just say centiPawn. By default this should mean in terms of classical piece values. It should be obvious that not all engines would value their pieces in the same (relative) way, so tying this to any particular piece would be wrong, IMO.

As such I think it is the default of the standard and not the GUI or Engine. Given that there is no standardization to be expected on the protocol side I think the GUI could step in instead as an additional feature provided to the users.

If it is a shortcoming of the standard, it should be fixed there. In the interest of all, problems should be fixed where they ly, rather than encouraging chaos by cleaning up the mess they make in other places. I don't see why you say that there is no standardization to be expected on the protocol side. If this is a problem that would merit fixing, it can be in the CCEP specs tomorrow.

[jdart]

Polyglot learning is not very sophisticated. As I understand it, it just records win frequency.

It won't learn novelties that are not in the book as constructed.

It also (as far as I know) doesn't use minimax to steer into favorable lines from an earlier point in the book.

An integration of a tournament manager with effective book learning would be very useful IMO. This could be used to explore an opening and improve the program's opening play.

--Jon

[hgm]

Polyglot learning is not very sophisticated. As I understand it, it just records win frequency.

It won't learn novelties that are not in the book as constructed.

It also (as far as I know) doesn't use minimax to steer into favorable lines from an earlier point in the book.

But such steering would happen automatically, wouldn't it? If a game gets lost, the statistics of all moves leading to it will suffer. So next time it tends to deviate at the earliest position where the statistics was not already so well established that the extra loss didn't have much impact.

An integration of a tournament manager with effective book learning would be very useful IMO. This could be used to explore an opening and improve the program's opening play.

Doesn't that exactly describe XBoard? It has an integrated tournament manager, and -mcBookMode can be used to switch on training of the book (including addition of novelties, etc.).

If you have any suggestions how that can be improved, they are most welcome. But so far I fail to see how what already exists differs from what you would like to have.

[ouachita]

DF13: A bit more intelligent and earlier adjudication of engine/engine games, 1-0, 1/2-1/2, and 0-1. Not sure what the selection criteria would be.

[gordonr]

Better than what CB has right now, where much meaningful and useful overnight deep analysis will not be stored for some reason.

I guess you're interested in having a decent analysis tree being generated rather than putting all the effort into finding the best move in the root position? I can understand why this would be useful.

I'm just curious because I believe some people use deep analysis in order to only find the best move in a position and do so while using a single engine. Surely analysing just the root is more effective?! Using multiple engines complicates things but even here, surely no need to generate a tree while no disagreement at root.

[Wwqlcw]

I have a friend writing his own engine + interface, and I've suggested to him he include something I call SAM -- Shoot A Move! It's a button click that randomly selects and plays one move from all possible moves in a given position. It's a good move sometimes; most times it's not so good. But it's quick and it's a move.

I had a young student just learning to use a clock who'd let time run out while staring at the board. I got to saying "Shoot a move... ANY move!" at her, just to get her unstuck. It not only got her unstuck, it became a way for her to analyze positions, since, afterwards, what was WRONG with SAM was crystal clear. She learned to eliminate bad moves one-by-one and to worry about which of the set of good moves she should play.

It originated from a chess variant my brother and I played as children, where we could demand that ONE MOVE (chosen by the opponent) in each game had to be determined by a roll of a die. We even played games where all of the moves were chosen by rolling a die.

It could also be used in online blitz games, where you're down to seconds and you have to move something/anything. Four or five SAMs might keep you alive long enough to win here and there. Online I see moves that are sheer acts of desperation every day; this would just formalize them. And of course it could be used to shake loose a recalcitrant student too afraid of consequences to do anything.

[jdart]

-mcBookMode can be used to switch on training of the book (including addition of novelties, etc.).

I was not aware of that option - it is interesting (seems to be not described in the Winboard HTML help, although it is in the xboard manual).

--Jon

[hgm]

Indeed. I gave up updating the HTML help. It takes too much time.

[kasinp]

DF13: A bit more intelligent and earlier adjudication of engine/engine games, 1-0, 1/2-1/2, and 0-1. Not sure what the selection criteria would be.

I would like to see that too.

For starters: an option to have GUI adjudicate the game once a tablebase position is reached. Without playing out silly 50-move sequences of K+R vs. K+R endgames as it can happen in Fritz GUI today.

PK