Elements of the ULTIMATE Chess GUI?

[giovanni]

Thanks Heiko. How much work do you think would be needed to add to xboard the capability to do interactive position analysis, kind of what IDEA does' in Aquarium program? I know you don't have Windows,

Where did you get that idea?

but it is a kind of analysis were the user goes back and forth from a given position recording the engine scores for any position being analyzed. Then, scores are backpropagated (minimaximized) to the root positions.

How does this differ from -mcBookMode in XBoard?

It is difficult to make an estimate of the required effort if I don't have the slightest idea of what exactly is requested. Is any kind of special output, or input controls needed for this feature? Would it just be like interactive analysis, showing one or more PVs in the Engine Output window? Would it produce a PGN tree that the user later can walk, annotated with score/depth information? Things like that would determine if it would take one day or three, once an exact specification is given.

Sorry Heiko, I don't know why but I thought you were a linux-only person. But actually it couldn't be true, since your are also producing the well known WinBoard program. Never mind, I am just getting too old...

Yes, the output is a minimaximized tree of the variations of a given position. The tree can be saved to disk for further refinement of the analysis. As default option program analyzes 5 seconds and 25 plies or so for each position and starts building a tree from there. However, the user is espected to heavily interact with the GUI selecting the most promising lines and cutting out the less relevant ones. In this thread, Rodolfo Leoni has shown what benefits this kind of interactive analysis can bring to. In his case, however, the tree was saved as an hash-file thanks to the Stockfish persistent hash version by Daniel Jose, but you perhaps get the idea of what the program can do:

http://www.talkchess.com/forum/viewtopi ... w=&start=0


A very simplified descriptior of IDEA would be here:

http://chessok.com/shop/index.php?main_ ... cts_id=724

[hgm]

Here is the page and some entries so far.

Of course I am very pleased that you rate WinBoard/XBoard so well on most counts. At the risk of seeming greedy, though: I am a bit puzzled that you rate the piece and board graphics only 6 out of 10. Because these are nearly infiitely configurable. E.g. for XBoard several dozens of piece themes are available, from the very conventional (like Alpha or Meridia) to the extreme. There also is the choice of nearly 100 square textures. Some examples:


Condal


Leipzig


Kilfiger


Fantasy


Freak

[gbtami]

Agreed. Sometimes these numbers has no meaning at all (for example at license line) sometimes are rather subjective, like this "Attrective design" line . Maybe it would be better to just use "+" and "-" instead of 0-10.

[hgm]

I don't quite understand this IDeA. From the description it seems it is just tree search. Which is just what the engine already does when you put in in analyze mode. So what does this add that the engine would not already do by itself when you just let it analyze from the root of the tree? The engine is supposed to be better at picking the relevant moves and limiting the anlysis to those (by reducing the rest) than the user. Or it would not have been a strong engine. It seems very ill advised to have the GUI meddle with this.

If there are some lines where the engine is prone to strategic misjudgement, and will only repent when you follow them very deeply, you just follow the line until the engine can see its mistake, and then propagate the score backwards by retracting the moves along the line. That always works for me. Minimaxing is very expensive compared to the alpha-beta search that the engine uses internally. The engine would try to get an exact score for every position the GUI gives it to analyze (it cannot do otherwise, which I think of as a protocol deficiency), which is very expesive compared to getting a one-sided score bound (as alpha-beta would do). The whole thing seems a tremendous waste of resources.

Is the advantage that you can easily step through the tree in the GUI, independent of what the engine is currently doing? In normal interactive analysis I can also step through the tree in any way I want, but this has the side effect that the analysis effort moves with it. But if such a decoupling is desirable, the proper way to do it seems to just set the engine analyzing on the root position, and allow probing of arbitrary positions in its hash table while it is doing that.

[syzygy]

I don't quite understand this IDeA. From the description it seems it is just tree search. Which is just what the engine already does when you put in in analyze mode. So what does this add that the engine would not already do by itself when you just let it analyze from the root of the tree? The engine is supposed to be better at picking the relevant moves and limiting the anlysis to those (by reducing the rest) than the user. Or it would not have been a strong engine. It seems very ill advised to have the GUI meddle with this.

As I understand it, IDeA builds a tree by expanding leaf nodes and assigning to the new nodes values obtained by running an engine on the corresponding positions to some depth. It then backpropagates the new values towards the root of the tree. Much like a book-building program, but one that you can run starting from an arbitrary position.

The difficult part of this process is how to deal with cycles in the graph (since it's not really a tree you're searching/expanding).

So basically it's a tree-management program. Instead of the user having to keep track of analysed positions and branches on a piece of paper, the GUI will do that for the user.

I don't know how nodes for expansion are chosen. I imagine the GUI uses some algorithm for that which the user can somehow steer.

If there are some lines where the engine is prone to strategic misjudgement, and will only repent when you follow them very deeply, you just follow the line until the engine can see its mistake, and then propagate the score backwards by retracting the moves along the line.

Yes, but hash tables tend to get overwritten, computers tend to be switched off or used for other purposes, etc. With IDeA you just have the relatively small tree on disk and can work on expanding it whenever you want. Also, it is trivial for the GUI to let many engine instances work on separate positions in parallel.

If you know about proof-number search, it's a bit how pn^2 relates to pn.

Btw, practically all of what I wrote is based on speculation, so if someone wants to correct my misconception of what IDeA really is, you are welcome!

[hgm]

As I understand it, IDeA builds a tree by expanding leaf nodes and assigning to the new nodes values obtained by running an engine on the corresponding positions to some depth. It then backpropagates the new values towards the root of the tree.

This is the impression I got too. But it means that you are replacing an alpha-beta search in the engine by a minimax search in the GUI. Which is horribly inefficient in comparison.

BTW, this sort of thing could be done much better if the root (aspiration) window could be set through the protocol. Then the GUI could really emulate an alpha-beta search on any tree it is holding.

As for the problem of volatility of the results: a save/load hash option could solve that. I storing such information would be considered a GUI task it would be more efficient if the GUI could request the hash entries it is interested in from the engine (score, depth and bound type).

[Leo]

Indispensable for me is access to Fritz's Lets Check feature.

[giovanni]

I don't quite understand this IDeA. From the description it seems it is just tree search. Which is just what the engine already does when you put in in analyze mode. So what does this add that the engine would not already do by itself when you just let it analyze from the root of the tree? The engine is supposed to be better at picking the relevant moves and limiting the anlysis to those (by reducing the rest) than the user. Or it would not have been a strong engine. It seems very ill advised to have the GUI meddle with this.

If there are some lines where the engine is prone to strategic misjudgement, and will only repent when you follow them very deeply, you just follow the line until the engine can see its mistake, and then propagate the score backwards by retracting the moves along the line. That always works for me. Minimaxing is very expensive compared to the alpha-beta search that the engine uses internally. The engine would try to get an exact score for every position the GUI gives it to analyze (it cannot do otherwise, which I think of as a protocol deficiency), which is very expesive compared to getting a one-sided score bound (as alpha-beta would do). The whole thing seems a tremendous waste of resources.

Is the advantage that you can easily step through the tree in the GUI, independent of what the engine is currently doing? In normal interactive analysis I can also step through the tree in any way I want, but this has the side effect that the analysis effort moves with it. But if such a decoupling is desirable, the proper way to do it seems to just set the engine analyzing on the root position, and allow probing of arbitrary positions in its hash table while it is doing that.

Ronald explained things much better than I. A critical issue is indeed that, with present GUIs, once you are done with the analysis, you cannot save it to disk for offline viewing or for further elaboration. As I said, the persistent hash version of stockfish somehow mitigates this problem, but it is not possible to extract a tree from the hash table according to Daniel Jose'. Also hash tables tend to be overwritten, with useless info replacing relevant one. Instead, with IDEA you are left with an useful tree that can be further refined, shared or offline viewed.
Besides opening preparation, IDEA is apparently much used by correspondence players that find more useful to do this kind of interactive analysis rather than doing infinite analysis. Apparently they are not bothered by the fact that, for optimal usage, they themselves need to prioritize moves for the engine. Anyway, the engine will still do some basic infinite analysis, so big things should not be missed. Also, a position in IDEA can be started by a set of high quality games, to make sure that relevant plans are not missed.
A good and small introductory video is here:

[hgm]

As I said, the persistent hash version of stockfish somehow mitigates this problem, but it is not possible to extract a tree from the hash table according to Daniel Jose'.

That sounds like nonsense. Virtually every engine more complex than micro-Max would keep all entries for positions close to the root that needed to be searched in its hash table, and can retrieve them from there.

Also hash tables tend to be overwritten, with useless info replacing relevant one.

Not if the engine is any good. They would keep the high-depth results, and only overwrite the useless low-depth results in the always-replace part of their hash table.

So it seems IDeA is just a crappy way to solve a problem that could be solved in vastly beter ways. But that beig said, it would be pretty easy to have a analysis mode where the engine would be set to anlyze a given position upto some depth, after which the score would be remembered and the best move would be played to repeat the process. And after a significant scre change, or a predetermined number of such steps, the moves could then be retracted, and the positions analyzed again to higher depth and with the changed score of the daughter, to see if it sticks with the original move (which would automatically back-propagate the score). And if it charges, start to follow the new move to the required depth, etc.

Scores and depths of the positions thus visited could be stored in a Polyglot book. Probes into the book could be used as a replacement of the analysis, i.e. if a position that according to the algorithm should be analyzed to a certain depth is already found in the book with a depth at least that large, it would use the score from the book, and not bother to analyze at all. That would ensure you could always restart an analysis that was aborted earlier.

Since most of the code to do this already exist (adding positios to the book, and probing it, letting the engine analyze), this would be a quite simple change. The main question is how exactly it should walk the tree. I.e. when should it decide to stop searching forward along the PV and start retracting the moves, and during this retraction, how much should it increase the depth of the already analyzed positions (to get more certain that the side branchess do not beat it).

[GONeill]

There are things I find I like from various programs that should be in my perfect GUI:

Chessmaster
Has a great "New game" screen. Select Human/Engine for each of Black and White and specify (possibly) different time controls for each. It's really easy to set up a new human/human or engine/engine or human/engine game, whereas I don't find this at all intuitive in Arena or Winboard.
Time controls for black and white can be different (ideally even using different systems).

Arena
While playing or analysing a game takebacks give a nice choice of Overwrite or New Variation.
DGT board support is good (via DGTDBDLL file), including takebacks, and I can quickly turn on/off DGT support from a button.
Starting a game from a set position or PGN file is easy.
List of installed engines and their settings is in an easily accessed (and modified) text file called ArenaENG.cfg so I can easily make global changes to engines (e.g. setting OPK key on all Chessmaster TheKing.exe personalities)

ArenaSwiss
Has option to set a tournament to pause after current game has finished or when a particular engine/person is about to play.
In engine tournaments can specify how many games are in each pairing (so how many games are played between two engines to get the result for the tournament)

TCEC
Ability to hold a tournament where openings are automatically replayed when white/black swap (so that both engines play the same opening line up to a set number of moves as both white and black). This should be an option in any engine game or tournament.

<No GUI?>
Ability to swap view between full display (e.g. including engine thinking lines, scores and history etc) and game mode display (just the board, clocks and move list) without losing any settings for each.