Elements of the ULTIMATE Chess GUI?

[sovaz1997]

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.

Do you mean somehow combine these things?
In the sense that when you do an analysis, it is stored in the database and compared with a specific engine, its version, its settings. And when this position is reopened, the analysis will be saved.

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

Do you mean somehow combine these things?
In the sense that when you do an analysis, it is stored in the database and compared with a specific engine, its version, its settings. And when this position is reopened, the analysis will be saved.

SCID is a chess GUI. And a chess database. And an engine platform. It is still a long way from what I want, but the GUI and the database must be combined.
You can say that Chessbase is also a GUI and a database. And Aquarium is also a GUI and a database.
But I suggest that none of them are really database systems. They just store chess information. A database system has a real database underneath.
One that is exposed, that is. I think Aquarium uses an ODBC connection for its queries, but I do not know what the underlying database is so I cannot query it directly.

[sovaz1997]

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.

Do you mean somehow combine these things?
In the sense that when you do an analysis, it is stored in the database and compared with a specific engine, its version, its settings. And when this position is reopened, the analysis will be saved.

SCID is a chess GUI. And a chess database. And an engine platform. It is still a long way from what I want, but the GUI and the database must be combined.
You can say that Chessbase is also a GUI and a database. And Aquarium is also a GUI and a database.
But I suggest that none of them are really database systems. They just store chess information. A database system has a real database underneath.
One that is exposed, that is. I think Aquarium uses an ODBC connection for its queries, but I do not know what the underlying database is so I cannot query it directly.

Now I understand what you are talking about. Yes, I think there is a definite advantage to having a general-purpose database for this: unlimited expansion options and more flexibility in data management. The ability to make your own requests of any complexity.
But I am afraid that such a database may take up more space and have a lower access speed.

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

Do you mean somehow combine these things?
In the sense that when you do an analysis, it is stored in the database and compared with a specific engine, its version, its settings. And when this position is reopened, the analysis will be saved.

What, do you mean like this:

tcec.png

[sovaz1997]

Like, if you analyze a position, then this analysis is stored in a database. Re-opening a position allows you to see the analysis you’ve made. Also, it can be used to fill the engine's hash table (by giving it quick launches of PV moves from the analysis).

[Dann Corbit]

{snip}
Now I understand what you are talking about. Yes, I think there is a definite advantage to having a general-purpose database for this: unlimited expansion options and more flexibility in data management. The ability to make your own requests of any complexity.
But I am afraid that such a database may take up more space and have a lower access speed.

If we use MonetDB, then the data will be accessed at (approximately) memory speed.
And the AMD 7nm Epyc stuff is coming this summer.
$3500 will buy you 18 TB of enterprise class SSD.
A little more, if you want m.2 gumsticks.

Compute power is not the problem.
Utilization of that power for optimal purpose is the problem.

[Fulvio]

If we use MonetDB, then the data will be accessed at (approximately) memory speed.

Do you have some concrete benchmark?
Let's say a 10 million games database: how long it takes to find the games (not just the positions, if I would like to study the ending I need to see the continuation) with for example a king+rook vs king+rook+pawn ending?

[sovaz1997]

{snip}
Now I understand what you are talking about. Yes, I think there is a definite advantage to having a general-purpose database for this: unlimited expansion options and more flexibility in data management. The ability to make your own requests of any complexity.
But I am afraid that such a database may take up more space and have a lower access speed.

If we use MonetDB, then the data will be accessed at (approximately) memory speed.
And the AMD 7nm Epyc stuff is coming this summer.
$3500 will buy you 18 TB of enterprise class SSD.
A little more, if you want m.2 gumsticks.

Compute power is not the problem.
Utilization of that power for optimal purpose is the problem.

In that case, this is a very good idea.

[sovaz1997]

If we use MonetDB, then the data will be accessed at (approximately) memory speed.

Do you have some concrete benchmark?
Let's say a 10 million games database: how long it takes to find the games (not just the positions, if I would like to study the ending I need to see the continuation) with for example a king+rook vs king+rook+pawn ending?

For the ending, there are other solutions - the Nalimov tables, the Syzygy tables. I don't think that the database is suitable for this.

[Fulvio]

For the ending, there are other solutions - the Nalimov tables, the Syzygy tables. I don't think that the database is suitable for this.

Oh... no positional search?
That's a very big limitation for the ULTIMATE Chess GUI...