Most wanted missing features for a chess GUI

[carldaman]

If I can determine offhand, in a few minutes, that most engines I normally use agree on the same move, I may start the deep analysis with a different root position, where there is disagreement.

If analyzing a corr game, then, even with no clear disagreement at the root position, I may still run several engines in infinite analysis mode first overnight, to make sure there are no hidden deeper threats that may be missed by the subsequent 'deep position analysis', where the engines will only spend several minutes on each position analyzed. The deep analysis is so called 'deep' not so much because of the time spent on each move, but rather this refers to drilling deeper into the position, by exploring multiple alternatives and follow-ups.

The deep analysis is primarily to be used overnight, or when one is not available to interact with the analysis. Otherwise, it's better to steer the analysis oneself, and this is where the real skill comes in - both analytical abilities and chess strength are a big plus at this stage.

Thanks for that. Just curious, if you do “run several engines in infinite analysis mode first overnight” and no disagreement, do you still do subsequent deep analysis? I agree with “better to steer the analysis oneself”, when possible, but I find it interesting to consider what the human “driver” is doing that is difficult/impossible to automate. I experiment with my own “deep analysis” code which does root only unless disagreement.

Well, if I also agree with the move, then I'll make the move and probably start the deep analysis from the ensuing position, unless there is a forced/obvious reply. The main thing is to focus on positions where significant branching can occur. If I don't like or understand the move(s) the engines suggest, I'll spend more time analyzing 'lesser' alternatives.

[ernest]

http://biglion.bplaced.net/ ? It is 0.245g.
http://biglion.bplaced.net/chess/ChessGUI.zip

OK I think I understand!

I downloaded the so-called 0.245f on 15/12/2013 20:22 (Paris time)
It contains ChessGUI.exe dated 15/12/2013 19:19
And it is the same as today (supposed to be 0.245g)

So maybe after all, what I previously downloaded was not 0.245f, but already 0.245g !!!

Matthias, is there a way to see the version on the exe or the zip themselves???

And last, what is the difference between f and g (what has been updated)?

Thanks!

[Matthias Gemuh]

So maybe after all, what I previously downloaded was not 0.245f, but already 0.245g !!!

Matthias, is there a way to see the version on the exe or the zip themselves???

And last, what is the difference between f and g (what has been updated)?

Thanks!

Version is displayed at top of GUI.

0.245g permits defining "Score Factor" for each engine.

[ernest]

Version is displayed at top of GUI.

Thanks!
Yes, very simple: to see it, I simply double click on ChessGUI.exe (I get an error message, but then there it is !!!)

[Matthias Gemuh]

Version is displayed at top of GUI.

Thanks!
Yes, very simple: to see it, I simply double click on ChessGUI.exe (I get an error message, but then there it is !!!)

ChessGUI.exe needs its support files to run without error.

[ernest]

Of course! but here I just want to see the version number!!!

[bhlangonijr]

I did a 'compilation' for all the suggestions:

1) Better multi-engine analysis, not only pairing engines to analyse a given position but rather produce a better analysis by combining them together (but how??)
2) Better deep analysis of chess positions and flexible rules for excluding moves and running the tree-walk of the variations (CB and Aquarium trees)
3) Provide per engine score and score-variance calibration. Allow user-defined win/draw probability functions which can be shared online with other users
4) Extend protocol/UI to be more interactive with users, allowing engines to send customized messages to them. One could have different type of messages: humorous, informative, etc.
5) Better - and earlier - adjudication of engine/engine games. Allow user-defined rules or tablebases results for adjudicating games
6) Allow adding multiple engines with different books for kibtzing/analysing a game
7) Better graphics (we are talking about an UI, right?) and cross-platform GUIs
8) Better move sounds
9) Voice recognition to input moves
10) Better reports/statistics of user's games


My initial intent with this thread was brainstorming towards a new concept for a chess GUI. I've read a lot of nice suggestions that could add something to that, although sometimes there is someone demanding something specific about a specific GUI.
Fritz is nowadays an exponent in this regard, making available nice features like using engines 'in the cloud' and the "Lets check" analysis. Although I think there is a lot of room for improvement.

[phenri]

(...)

6) Allow adding multiple engines with different books for kibtzing/analysing a game

(...)

Item 6 contains two different ideas.
The idea was suggested to have several books explorer for the same chessboard.
But also adopt the reading of .ctg format (CB) knowing that it is very common and almost inevitable as were .pdf, .jpg, .doc, .zip, ...

[hgm]

5) Better - and earlier - adjudication of engine/engine games. Allow user-defined rules or tablebases results for adjudicating games

From the discussion it seems there is a genuine problem with engines trying to swindle each other in a drawn position, when they both use tablebases. (In won positions both would know the best move, and should play it instantly.) So I am considering adding a feature for that in WinBoard.

I am currenly leaning to adding options /first/secondFastDraw N, which would limit the search depth of the engine to which it applies to N ply as soon as the GUI detects that the root is a theoretical draw. If both engines would have the option set, (i.e. non-zero, as the default value N=0 would switch the option off), the GUI would adjudicate draw.

This would not corrupt the test results by awarding draws to engines that might not know how to actually draw against engines using EGT. They would still have to play for it, against an opponent that would make some kind of effort to not play needlessly careless. By setting N the user can decide how he want to trade swindle effort for speedup, but my guess is that N=3 would be a satisfactory value, and even N=7 would have most top engines move instantly.

6) Allow adding multiple engines with different books for kibtzing/analysing a game

This was not how I understood it (but I admit I did not really understand it at all). The books were not engine books, right? If UCI engines have books at all, can they show their content through the GUI? I think the request fro the number of engines was not related the the number of books, which were GUI books.