Elements of the ULTIMATE Chess GUI?

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

[hgm]

I am naturally very interested in what GUI features people would appreciate. So I compiled the following list, giving an overview of what people mentioned in this trhead so far. With a comment of my own indicating whether this feature is already implemented in WinBoard/XBoard, or how far we are away from that:

Code: Select all

- Winboard and UCI compatibility
  CHECK
- Attractive design, board and piece set/s ( and including attractive multi-PV analysis display - unlike Arena)
  CHECK (although 'attractive' is a subjective qualification)
- Round Robin, Gauntlet and Swiss Tournaments
  CHECK
- Custom Opening Books (hopefully with ability to import/convert other books)
  CHECK
- Ability to clearly display UCI options for engines with a LOT of options (Rodent, Texel, Pro Deo, Gambit Fruit etc)
  CHECK? (Might benefit from an extra scroll bar or paging?)
- TB usage/adjudication
  CHECK
- Openings study features
  ? (Variaion trees: CHECK)
- Open EPD and PGN files
  CHECK
- Game user-adjudications
  CHECK
- Attractive Engine logo and rating display during matches
  CHECK, no ratings
- Rodent and Pro Deo built-in (assuming permission from Pawel and Ed Wink )
  YEGH! :-(
- Beautiful engine tournament crosstables and engine rating changes on-the-fly (like Arena, but with beautiful visuals)
  Not implemented (relies on external dedicated tool, which seems preferable)

- Cross platform.
  CHECK (available as WinBoard fro Windows, and as XBoard for Liux / Mac)
- Lite on hardware resources.
  CHECK
- Highly customizable
  CHECK
- Vector images
  Only in XBoard (SVG); WinBoard has scalable font-based piece rendering, though

- Very flexible adjudication options. That is an area where ChessGUI is ahead of anything else.
  Pretty basic (But should be trivial to add)
- For a repeating time control, allow it to be specified in minutes and seconds and not just minutes
  CHECK

- A "Guess the Move" feature like in this prog: https://sites.google.com/site/fredm/. Scroll a little bit down.
  CHECK? (Is't this what 'training mode' does? I never used that.)

- It is important to turn off all the features not wanted, and to make sure that blank features do not continue to be displayed.
  CHECK

- Knockout Tournaments
  Not implemented
- Ability to run TLCV broadcasts.
  CHECK
- Adjustable adjudication settings.
  Not so many

1. Wilhelm would show the hot squares for winning endgames graphically. A fabulous teaching tool.
  No
2. Arena has a setting that shows every attack square for the side to move. Truly ingenious. It could be improved on by drawing arrows from the attacking pieces.
  No
3. There should be a feature to play the pv like a movie. If there are two engines, pick a pv and play it. Then pick the other pv and play it.
  CHECK
3b.And the third option would be to play the combined pv to the point where they differ, if the first move or some of the first moves are the same.
  No
4. Be able to store game logs as a collection of EPD records (that's for me).
  No
5. Heat maps from a collection of games would be nice.
  No

- don't lag and don't cause losses on time, like Arena does
  CHECK
- don't force user to work on text files, hand-type engine paths etc. like Winboard does
  CHECK
- exit gracefully, killing the engine processes (problems with Arena again)
  This could be a fundamental Windows problem
- extend both Winboard and UCI protocols by adding "chat" command, by which engine can display something in a separate window (comments, evaluation details, trash talk, whatever). Rodent would gladly talk to its opponents, but unfortunately it cannot rely on "info string" UCI command, which is often ignored
  CHECK (both in the Engine Output window and as separate popup notice)
- if the engine supports either UCI_Elo or some kind of level command (Stockfish style), implement usage mode that increases level when user wins and decreases it when user loses
  ot implemented
- integrate PolyGlot book creator, so that it can be used from the GUI level (Scid allows editing existing books by changing move probabilities, but I'd like to be able to pick several pgn files for white and for black, and then create a book at one go)
  CHECK
- integrate stuff like ChessArtist by Ferdinand Mosca (it is a Python script that returns game analysis)
  ?
- Winboard is great with its time odds implementation
  CHECK
- automatically create web pages with a pgn of a current game/current collection of games
  Uses external tool for that

- support for all the current standards of Chess960.
  CHECK
- swiss tournaments with 5000 engines or more.
  CHECK (?) (Not sure whether there is currently a limit to the number of players, but if there is, increasig it should be trivial)
- rated tournaments/matches
  ? (Seems better to leave that to an external tool of choice?)
- swiss tournaments with initial bonus points so that strong engines never face much weaker ones even in first round.
  Not implemented (McMahon system)
- swiss tournaments with scaled Time Controls so that weak engines play faster than strong engines.
  ?

- Supporting two computer match via wireless Wi-Fi and not causing connection issues (game stop midgame). Alternatively Null-Modem USB works fine.
  Doesn't seem a GUI task
- 6-men syzygy adjudication.
  No. (But EGT-based adjudication is a perverse feature...)
- Draw adjudication (like cutechess)
  Not implemented
- Resign adjudication
  CHECK

- The possibility to perform interacrtive analysis a la 'IDEA' in Aquarium.
  No

- When there is an engine/engine contest, show the first place the pv's disagree. TCEC uses an @ sign by default, but you can also configure it to use color.
  Not implemented

- I also like the graphs for depth/time/speed/tb hits.
  Not implemented

- Open source
  CHECK
- Work on Windows,Linux,Mac OS...
  CHECK
- Customizable
  CHECK (?)
- Possibility to use a scripting language to make plugins : best way for users to add new features to the program
  ?

- Ability to run multiple instances of the GUI at the same time, either each running totally different matches/tournaments, or all working on the same one.
  CHECK

- 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.
  Not sure what your gripe is with how WB does it now 
- Time controls for black and white can be different (ideally even using different systems).
  Only time odds

- While playing or analysing a game takebacks give a nice choice of Overwrite or New Variation.
  CHECK (?)
- DGT board support is good (via DGTDBDLL file), including takebacks, and I can quickly turn on/off DGT support from a button.
  No. (Better through pseudo-engine?)
- Starting a game from a set position or PGN file is easy.
  CHECK
- List of installed engines and their settings is in an easily accessed (and modified) text file 
  CHECK
- Has option to set a tournament to pause after current game has finished or when a particular engine/person is about to play.
  Not implemented
- In engine tournaments can specify how many games are in each pairing
  CHECK
- Ability to hold a tournament where openings are automatically replayed when white/black swap
  CHECK
- 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.
  Could be better

I put a question mark for features I did not understand what they should do.

[jdart]

Arena's engine setup screens are nice, and they make it easy to modify the engine settings after you have set them up, or do a one-time modification when you are setting up a tournament. Better than Fritz in this area IMO.

I use ChessBase extensively. It has a lot of features for game editing, and has publishing features. Of course integration with databases, both local and cloud-based. I use the "Novelty Annotation" feature a lot: this will go through the online database and highlight where the game's first novelty appeared, as well as key variations. Chessbase can create and edit book files (.CTG format only I think) and classify openings. It is a great program, but somewhat quirky, buggy and inconsistent in how it does things. The integration with Fritz is somewhat awkward: the two programs are different and have overlapping features. ChessBase also can be slow sometimes, even on a fast system.

None of the UIs I have have really sophisticated opening book features, such as handling multiple book formats, using backsolving (as in Bookup), support for learning via dropout expansion, etc. There is some room for innovation here I think.

--Jon

[gbtami]

- integrate stuff like ChessArtist by Ferdinand Mosca (it is a Python script that returns game analysis)

See https://github.com/fsmosca/chess-artist

- Possibility to use a scripting language to make plugins : best way for users to add new features to the program

You can see an example for this at Geany (editor) here https://plugins.geany.org/index.php?site=1.24/geanypy