Most wanted missing features for a chess GUI

[bhlangonijr]

Better deep analysis features would also be welcome. We're still in the dark ages when it comes to such features.

Interesting but can you elaborate a bit more on "Better deep analysis"? What tools/features/information would you like to have in?

[carldaman]

Better deep analysis features would also be welcome. We're still in the dark ages when it comes to such features.

Interesting but can you elaborate a bit more on "Better deep analysis"? What tools/features/information would you like to have in?

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

Aquarium is supposed to be an improvement in this area, but it is also very inefficient in that it will keep analysing useless variations if left unattended. Besides, Aquarium is totally counterintuitive, and extremely unfriendly to the end-user. Things that ought to be basic and straightforward are not (such as saving one's analysis to a pgn file and porting it to another GUI).

The tree functionality in Aquarium is very messy, although it can potentially store more useful info than CB ctg trees. In addition, Aquarium trees fail to recognize reverse/mirror transpositions, an essential feature if you study and play such openings as the QGD or transpositional reversed openings (starting with 1. Nf3, for example).

[bhlangonijr]

It would be nice to have a window/terminal (not pop ups!) in which the engine dumps there whatever it wants, comments, emoticons etc. that it is part of a protocol. Is that the geeky dashboard you mentioned?
Miguel

A window for engines interacting with the user would be great. It is pretty much in line with what Julien Marcel suggested. A geeky dashboard would display a lot of technical information, benchmarks comparisons and other things related to the engine's thinking process. A good analogy would be the telemetry dashboard we have for racing cars. It shows a lot of technical details about the car's engine in real time.
The chess engine "geeky dashboard" would display for example, charts with cpu usage by the engine process over time, charts with NPS, average of time-to-depth, percentiles, etc.

[Rebel]

I personally would like to have a geek dashboard with all detailed information from the chess engine thinking process.

ChessPartner has it for over a decade, see the 10 screenshots.

http://www.lokasoft.nl/rebel12.aspx

You can define as much tabulators as you want.

[hgm]

An integration of a GUI with some kind of automated book learning facility would be interesting. Some engines support this but I am not aware that the common GUIs do.

-Jon

Polyglot supports book learning. It cann be used with any UCI engine on any GUI.

[Matthias Gemuh]

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

...

That has been on the to-do list of ChessGUI for quite some time.
I always divide SF scores by 1.9 before they make sense.

[hgm]

Fritz/CB ctg trees can have variable move weights based on learning, independent of engine used. This is nice, but the Fritz book learning feature cannot add new moves to the tree (the way old Mchess used to do, for example).

Not sure what you mean by 'Fritz/CB trees'. (I don't have Fritz.) Is this just a small book starting from an arbitrary position? WinBoard has a "Monte-Carlo book mode" where it builds a book from engines playing games. This does add moves to the book. (If all moves in the book for the given position have been played with relative frequencies they deserve based on their merit, in generates a book miss, so that the engine gets the opportunity to suggest a new move.)

What I'd like to see more GUIs have is the ability to exclude multiple moves from infinite analysis. Some GUIs can do this already.

Indeed, WinBoard/XBoard already supports that.

Better deep analysis features would also be welcome. We're still in the dark ages when it comes to such features.

Well, I am not familiar with "deep analysis" at all. Apparently you mean something different than just letting an engine run for a long time in analysis mode (possibly with multi-PV on). What would you want to have the GUI do here? Follow up the moves suggested by the engine, and start analysing from there? Order multi-PV searches to get alternative moves, and follow up those as well, to build a tree?

There seems a risk in having the GUI take over the part of the search close to the root from the engine. There also is an efficiency problem: for efficient search you only need to prove moves are not better than a certain score bound, and not always know their exact score, which takes enormously longer to calculate. But currently no commands exist to ask this of an engine, either in WB or UCI, so that obviosly there also are no engines that supports this.

I have always though that it would be very useful to add a command

window ALPHA BETA

to the protocol, to set the aspiration window for the upcoming search (and suppressing re-searches on fail low or fail high). This should be quite trivial to implement, and offers a very flexible tool to do things from the GUI that otherwise only an engine could do.

[carldaman]

Fritz/CB ctg trees can have variable move weights based on learning, independent of engine used. This is nice, but the Fritz book learning feature cannot add new moves to the tree (the way old Mchess used to do, for example).

Not sure what you mean by 'Fritz/CB trees'. (I don't have Fritz.) Is this just a small book starting from an arbitrary position? WinBoard has a "Monte-Carlo book mode" where it builds a book from engines playing games. This does add moves to the book. (If all moves in the book for the given position have been played with relative frequencies they deserve based on their merit, in generates a book miss, so that the engine gets the opportunity to suggest a new move.)

What I'd like to see more GUIs have is the ability to exclude multiple moves from infinite analysis. Some GUIs can do this already.

Indeed, WinBoard/XBoard already supports that.

Better deep analysis features would also be welcome. We're still in the dark ages when it comes to such features.

Well, I am not familiar with "deep analysis" at all. Apparently you mean something different than just letting an engine run for a long time in analysis mode (possibly with multi-PV on). What would you want to have the GUI do here? Follow up the moves suggested by the engine, and start analysing from there? Order multi-PV searches to get alternative moves, and follow up those as well, to build a tree?

There seems a risk in having the GUI take over the part of the search close to the root from the engine. There also is an efficiency problem: for efficient search you only need to prove moves are not better than a certain score bound, and not always know their exact score, which takes enormously longer to calculate. But currently no commands exist to ask this of an engine, either in WB or UCI, so that obviosly there also are no engines that supports this.

I have always though that it would be very useful to add a command

window ALPHA BETA

to the protocol, to set the aspiration window for the upcoming search (and suppressing re-searches on fail low or fail high). This should be quite trivial to implement, and offers a very flexible tool to do things from the GUI that otherwise only an engine could do.

Re: Fritz books/trees - the CB native opening book files (with the .ctg extension) are also known as trees, and can be linked to any engine loaded in the Fritz GUI, so you could have multiple engine all using the same book when playing and taking turns updating it, by changing the move weights depending on game eval and results, which is how 'learning' is implemented in Fritz.

The major issue is that no new moves can be automatically added to the book by way of 'learning'; this can only be done manually by the end user. He can add promising individual moves by playing the moves out on the board, or could import entire .pgn files into the .ctg tree, which can be done easily thru drag-and-drop. Of course, when importing games, both good AND bad book moves will be imported.


Re: CB deep analysis -- an analysis tree will be created, but this is just a tree of variations (with engines analyzing candidate moves for both sides) within the game notation itself, meaning that no special or separate tree file will be created as a result of deep overnight analysis. All the analysis should be stored within the game notation, at least it's supposed to, if all goes well...

In contrast to Chessbase/Fritz, Aquarium uses its own proprietary tree file format for both openings and deep analysis, and the deep analysis can be integrated into pre-existing trees. This should work better in theory, but is much more complicated and difficult to work with than what Chessbase offers.

Both CB/Fritz and Aquarium allow you to define parameters to narrow the choice of candidate moves accordingly.

Re: move exclusion -- Aquarium and WB have this feature, perhaps other GUIs also ?

Regards,
CL

[hgm]

Re: Fritz books/trees - the CB native opening book files (with the .ctg extension) are also known as trees, and can be linked to any engine loaded in the Fritz GUI, so you could have multiple engine all using the same book when playing and taking turns updating it, by changing the move weights depending on game eval and results, which is how 'learning' is implemented in Fritz.

The major issue is that no new moves can be automatically added to the book by way of 'learning'; this can only be done manually by the end user. He can add promising individual moves by playing the moves out on the board, or could import entire .pgn files into the .ctg tree, which can be done easily thru drag-and-drop. Of course, when importing games, both good AND bad book moves will be imported.

There seems to be a bit of a conflict here between playing by the book, and adding new moves. To explore new moves, you would intentionally have to deviate from the book, which is something you would never want to do when you want to rely on the book for strong play. Even adding moves only when you get out of book at the end of a line is not satisfactory: as soon as one move was added, it would no longer be out of book in that position, so you would never get any others. So no branching, just a single very deep line.

This is why I added the MC book mode in WinBoard, intended for creating or expanding a book. In this mode it does not try to use the book for strength, and often intentionally forces weak moves in order to explore them, in the hope engines will find an improvement. And often does not play a book move at all, despite the fact it has many available for the position, to see if the engine can come up with a new move, to add that to the book. That differs quite a lot from how you would want a book to affect move choice in normal play. But if you especially conducted matches or tournaments for building a book, you use this book mode with it. (E.g. with a multi-cycle round-robin of engines carefully handicapped by time odds to make them equally strong.)

Isn't this basically already exactly what you want? Currently the user interface for this is a bit flimsy, as it does the book updating purely in a memory buffer, which cannot even be saved afterwards (the idea being that the PGN file where the games were saved contains the same information, and could simply be added to the book with existing software, even for book formats not supported by WinBoard). But it would of course be trivial to provide menu items for loading this memory buffer from an existing book file, and saving it back on the book file afterwards. (In a sense you can already do the latter with the 'Save Games as Book' menu item, when the game file is empty. But that is a bit kludgy.)

About adding moves by hand: You can do that in WinBoard, but so far only by typing the move in the Edit Book dialog, next to the moves already displayed there for the current position. This is a bit cumbersome, and indeed I was planning to somehow allow entering moves by playing them. One way to do it was add a button for that in the Edit Book dialog: you could press the button after you played the move (in Edit Game mode), to add it to the book for the previous position, with some standard weight. (The need to enter a weight was what initially made me go for the typing solution.)

Re: CB deep analysis -- an analysis tree will be created, but this is just a tree of variations (with engines analyzing candidate moves for both sides) within the game notation itself, meaning that no special or separate tree file will be created as a result of deep overnight analysis. All the analysis should be stored within the game notation, at least it's supposed to, if all goes well...

OK, so if I understand this well, the GUI would perform some kind of tree walk with the engine in analysis mode, and record the result as (annotated?) recursive variations in PGN format.

In itself this is not difficult to implement, but the usefulness stands or falls with the algorithm that would be used for walking the tree. How would a GUI decide which alternative moves to try, and how deep it should follow the PV suggested by the engine?

[hgm]

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.