Elements of the ULTIMATE Chess GUI?

[sovaz1997]

There doesn't seem to be much interest...

I guess the point is that it doesn't really seem to do anything other GUIs don't do already. It just presents it in a slightly different way on the screen. Which some people will like, but most others won't, as this is purely a matter of taste, an many tastes are possible, each having their own favorites.

Probably yes. Because while we need more ideas, I think.

[Dann Corbit]

There are lots of things that chess GUIs do not do that I need them to do.
They don't teach me how to play better.
They do not take millions or billions of analyzed EPD records or chess games with annotation and then minimax it (using a chess engine to fill in the holes where data is missing).
They do not analyze games and bare EPD records and produce standardized EPD with the annotation of the analysis attached to the EPD records.
They do not show strategy.
They do not have good statistical information.
They do not store their chess information in a real database (one that I can manipulate with SQL, though the chess systems that use CQL are interesting)
They do not store chess engine configuration information in a database.
They do not graphically display the best place to move chessmen as a function of statistics.

Quite frankly, I have been tempted to make my own, but I find that I can get by with the various utilities I have created so I am not motivated enough to do it.

Even more so, I think it would be great for beginners to have better tools.
Imagine, for instance, a GUI that would show a raw beginner how to win with a king and a rook against a bare king by explaining the process graphically (showing the attacked squares and the little wall that the king makes)
Then take it up a little notch and explain how to win with two bishops (graphically demonstrating how they can force the king into the corner and mate).
One more notch to graphically explain the KBN vs k checkmate.

In my view, chess GUIs are woefully inadequate systems that show you a picture of the GM players and will scroll through a game.
They have been able to do that for 20 years, and have not advanced much.

[Dann Corbit]

Ok, at this stage, I see 5 modules:

+ Analysis
Analysis module Allows you to view PGN-files, view games, analyze them with engines, comment.

And EPD records. Saving the analysis in a database. (Hopefully accessible with both SQL and CQL).

+ Testing
Module testing chess engine. Allows you to flexibly set test parameters (for example, SPRT testing or testing with a fixed number of games), the ability to set the testing queue, the ability to pause testing.

+ Tournament
Creating tournaments engines with different modes. Also, the generation of Web-pages for broadcast tournament on the network.

+ Playing
Game Mode. Ability to play against the chess engine or against yourself.

+ Learning (optional)
Learning mode. The ability to create interactive books on chess.

Are these modules enough? Or can some of them be combined, and some divided? Write your suggestions. When we select the modules, it will be possible to start working each separately.

Teaching. That is the most important task, and is missing from all of them.
And, no, playing a video that came with the chess database does not count.

white-knight-first-twenty-ply-winning.png

black-knight-first-twenty-ply-winning.png

[hgm]

There are lots of things that chess GUIs do not do that I need them to do.
They don't teach me how to play better.

Yeah, and they also don't serve coffee... Why do you think teaching you to play better would be the task of an interface? Beside, XBoard has a 'training mode', and although I have never used it and am not sure what exactly it does, it sounds like it exists for exactly this purpose. The easily overlooked 'sting' in your statement is the word 'them'. It is very easy to compile a list of things you want to have done. But that doesn't automatically imply a Chess GUI should do them. I'd like to stack truckloads of money, but I would not go so far as expecting a GUI to provide me with it, and complain that it cannot.

They do not take millions or billions of analyzed EPD records or chess games with annotation and then minimax it (using a chess engine to fill in the holes where data is missing).

Not clear why you would need a graphical interface for this. What exactly would you like to be shown to the user that gives him any information about this task? It sounds like an off-line job, for which the only thing that can be monitored is how far it is from being completed. That makes it fall in the coffee category.

They do not analyze games and bare EPD records and produce standardized EPD with the annotation of the analysis attached to the EPD records.

Isn't that what the similarity test does (on collections of EPDs)?

They do not show strategy.

Now what do you mean by that? How would one 'show strategy'? Why should a GUI, which by definition would not know anything about the game other than perhaps the rules, (as all intelligence is supposed to be deligated to the plugins known as engines) be able to do this? Whatever it means, it sounds like an engine task.

They do not have good statistical information.

Again, it is not the task of GUIs to 'have' information. Just to display it. The information would be in a database (e.g. PGN collection). XBoard can show WDL statistics of such collections filtered in many ways. So what do you mean by 'good' here? What aspects do you want to have statistics on?

They do not store their chess information in a real database (one that I can manipulate with SQL, though the chess systems that use CQL are interesting)

This seems like putting requirements on how they work internally. If you want SQL-format databases, you should use SQL.

They do not store chess engine configuration information in a database.

Configuration information? You mean the option settings? Surely most GUIs would store that? In XBoard you can make any engine settings 'persistent', having it saved in its engine list. Or is the snag here that you don't consider that a 'database'?

They do not graphically display the best place to move chessmen as a function of statistics.

This is also a bit vague. You mean the best move in a given position?

Even more so, I think it would be great for beginners to have better tools.
Imagine, for instance, a GUI that would show a raw beginner how to win with a king and a rook against a bare king by explaining the process graphically (showing the attacked squares and the little wall that the king makes)
Then take it up a little notch and explain how to win with two bishops (graphically demonstrating how they can force the king into the corner and mate).
One more notch to graphically explain the KBN vs k checkmate.

Again, this seems to be something involving knowledge about game strategy, and thus by definition a task for an engine rather than a GUI. It is the engine that should decide which squares should be marked in which way (e.g. which color) to make the educational point it wants to make. And in XBoard it can already do that.

[sovaz1997]

I do not think it will be just a chess GUI. It will be something like a chess system with unlimited possibilities. Therefore, we need the ability to create plug-ins in the future.

Also, it seems to me, one of the important things: the integration of machines and the parallelization of the system on them in the local network.

Regarding the preservation of analyzes: yes, this is a very important thing. It should be possible to save as much as possible everything that happened in the program. All analyzes are ranked by engines, their versions and their settings.

------------

Maybe it will be a universal GUI and microservices, which can be both plug-ins and embedded programs. These microservices will be managed by the built-in task manager, and all I / O will be saved as history. This is so for reflection. There are many subtleties that I did not take into account.

[hgm]

It seems to me that by expanding the scope that way, the project will soon drift off into the area of science fiction.

Having / managing a "let'check"-type database is nice, but it should not be connected to any particular GUI. The proper way to go about that would be to define an open standard for how to interface with it, so that any GUI can implement it.

[sovaz1997]

It seems to me that by expanding the scope that way, the project will soon drift off into the area of science fiction.

Having / managing a "let'check"-type database is nice, but it should not be connected to any particular GUI. The proper way to go about that would be to define an open standard for how to interface with it, so that any GUI can implement it.

Of course, many ideas will eventually have to be discarded if they are difficult to implement, but not the most necessary.
But on a universal database standard, we can work, I agree.

[Dann Corbit]

There are lots of things that chess GUIs do not do that I need them to do.
They don't teach me how to play better.

Yeah, and they also don't serve coffee... Why do you think teaching you to play better would be the task of an interface? Beside, XBoard has a 'training mode', and although I have never used it and am not sure what exactly it does, it sounds like it exists for exactly this purpose. The easily overlooked 'sting' in your statement is the word 'them'. It is very easy to compile a list of things you want to have done. But that doesn't automatically imply a Chess GUI should do them. I'd like to stack truckloads of money, but I would not go so far as expecting a GUI to provide me with it, and complain that it cannot.

I am not asking you to rewrite winboard to do that for me. But that is what I want in a chess GUI.

They do not take millions or billions of analyzed EPD records or chess games with annotation and then minimax it (using a chess engine to fill in the holes where data is missing).

Not clear why you would need a graphical interface for this. What exactly would you like to be shown to the user that gives him any information about this task? It sounds like an off-line job, for which the only thing that can be monitored is how far it is from being completed. That makes it fall in the coffee category.

I want a GUI to do everything. It is easier that way, because I am a visual guy.

They do not analyze games and bare EPD records and produce standardized EPD with the annotation of the analysis attached to the EPD records.

Isn't that what the similarity test does (on collections of EPDs)?

Not remotely. I want a collection of (say a thousand at a time) EPD records with no analysis to be analyzed at a depth or time that I want per record. I want the output to be standard EPD with full analysis. I want the analyzed records to be pushed into a database.

They do not show strategy.

Now what do you mean by that? How would one 'show strategy'? Why should a GUI, which by definition would not know anything about the game other than perhaps the rules, (as all intelligence is supposed to be deligated to the plugins known as engines) be able to do this? Whatever it means, it sounds like an engine task.

It is completely clear to me that this is possible.
As for, "It is an engine task.", that's wrong. It is a cooperation between engine and GUI.
See this:
info depth 21 seldepth 42 multipv 1 score cp -3003 nodes 92448997 nps 10505567 hashfull 124 tbhits 1216 time 8800 pv b5d4 c4c5 b4d3 c5d5 d3b4 d5e5 b4c6 e5e4 b7c8 c7b6 d4f5 e4f5 a4f4 f5g5 a6d3 c3c2 f4f5 g5g4 f5f1 h6h2 c8b7 h2c7 b7a6 c7c6 d3b5 c6c7 b5e2 g2e2 f1h1 c2c1q h1c1 c7c1
That's semi-useless to a human.
The engine spits out analysis. The engine and the GUI should cooperate to produce analysis that is useful.
An example of a reasonable goal is to produce the human readable analysis like the Chessmaster version did that explained the analysis.

They do not have good statistical information.

Again, it is not the task of GUIs to 'have' information. Just to display it. The information would be in a database (e.g. PGN collection). XBoard can show WDL statistics of such collections filtered in many ways. So what do you mean by 'good' here? What aspects do you want to have statistics on?

The function of the GUI is to collect data and show it in a meaningful way. I want, for instance, the GUI to eat the entire terabyte of data from lichess and atomize the PGN into EPD and collect the win/loss/draw statistics and decorate a database with that information, and then display that information in a beautiful way. Don't worry, I am not asking you to do this. In fact, I already have it.

They do not store their chess information in a real database (one that I can manipulate with SQL, though the chess systems that use CQL are interesting)

This seems like putting requirements on how they work internally. If you want SQL-format databases, you should use SQL.

In fact, I do use SQL. I have all my data stored in SQL Server. I also have it stored in PostgreSQL and SQLite. At some time, I will probably change to MonetDB. But the point is I want to attach to the data with my GUI. I want to query the data with my GUI. I want a pictorial view of what my data looks like. I want to see the analyzed chess tree from a given node, containing the engine analysis along with the statistical data, all the child records and the parent record.

They do not store chess engine configuration information in a database.

Configuration information? You mean the option settings? Surely most GUIs would store that? In XBoard you can make any engine settings 'persistent', having it saved in its engine list. Or is the snag here that you don't consider that a 'database'?

Yes, storing these settings in files is primitive pete. Suppose, for instance, that I want to organize a contest with 1000 engines. I want each engine to have 30 threads and I want those engines to ponder. I want 12 other settings changed, some of which would require individual updates for engines. Now, if the settings were in a database, I could change them all with a single SQL query which would take 1 second. That's what I want.

They do not graphically display the best place to move chessmen as a function of statistics.

This is also a bit vague. You mean the best move in a given position?

I mean, with a few terabytes of PGN, I can have a really good idea of the probability of winning, considering the win/loss/draw statistics. I would also like the GUI to calculate for me if a move overperforms as a function of Elo. IOW, if the move allows a lower Elo entity to prosper over a higher Elo entity. Also, I will have almost all the positions in my database analyzed. So I would like to combine the analysis from the engines with the statistics from the actual games to get a superior understanding of the value of a position and the value of the possible forward moves

Even more so, I think it would be great for beginners to have better tools.
Imagine, for instance, a GUI that would show a raw beginner how to win with a king and a rook against a bare king by explaining the process graphically (showing the attacked squares and the little wall that the king makes)
Then take it up a little notch and explain how to win with two bishops (graphically demonstrating how they can force the king into the corner and mate).
One more notch to graphically explain the KBN vs k checkmate.

Again, this seems to be something involving knowledge about game strategy, and thus by definition a task for an engine rather than a GUI. It is the engine that should decide which squares should be marked in which way (e.g. which color) to make the educational point it wants to make. And in XBoard it can already do that.

No. The engine can calculate these things for me. I can have statistical tools analyze things for me. I can have GPU card engines like LCO offer their opinions. But it is up the the GUI to present the information in a valuable way.

All the objections are exactly why I say that GUI chess systems have not evolved in a way that I like.
They still do the same things that they did 20 years ago.
You imagine that a GUI cannot teach. But I think that with statistics, math, engine analysis, expert coding with GM insights, etc., a chess GUI can do all that I have dreamed of and more.

Now, I do not expect a hobbyist to do this for me.
I have accomplished parts of these things.
My friend Les Fernandez has helped me with chess analysis tools.
I have dozens of C utilities I have written for chess processing.
So many of the things that I want I can accomplish to some degree.
But other things are comically lacking.

For instance, if I read in a database of one million games into my chess GUI, I can find a game, and scroll through the moves.
If they have computer analysis within the game, they might even have helpful data about the moves.
But why is it that I cannot load my billion EPD records into the database so that I have deep and interesting data directly attached to the game positions? I do not know of any chess database that does this. A shame, too.

[Rebel]

Many of the ideas you mentioned I would love to see them in a GUI as well but it seems to me the nature of the ideas fit better in a database program like SCID.

[Dann Corbit]

Many of the ideas you mentioned I would love to see them in a GUI as well but it seems to me the nature of the ideas fit better in a database program like SCID.

The GUI needs to be attached both to engines and to databases.
Otherwise, it is just a thing that scrolls through games.