Is there any project coming to solve chess?

[Jouni]

My suggestion: first prove, if 1.g4 loses or not. Then 1/20 of problem solved .

[Uri Blass]

I suggest first to have a solving chess ranking list.

Engines get 10000 random positions from a pgn and need to decide for every position if it is a win for white or a draw or a win for black or they do not know.

The leader in the ranking list is an engine that identify correctly more positions in the list with a result.
Of course the leader may have bugs and if people can find a position that the leader decides wrong about it then it is a good reason to take the leader out of the list.

[LucianGVx]

Yes, https://www.chessdb.cn/queryc_en/

[Jouni]

Evaluation in chessdb for 1.g4 changes everyday. But just now it's -1,45.

[Dann Corbit]

I suggest first to have a solving chess ranking list.

Engines get 10000 random positions from a pgn and need to decide for every position if it is a win for white or a draw or a win for black or they do not know.

The leader in the ranking list is an engine that identify correctly more positions in the list with a result.
Of course the leader may have bugs and if people can find a position that the leader decides wrong about it then it is a good reason to take the leader out of the list.

If an engine uses any kind of pruning beyond pure alpha-beta, then the output cannot be a proof of anything. Null move pruning, for instance, is unsound. Of course, it provides heuristic evidence, but that is not a proof.

Tablebase files were used in the proof for checkers. Perhaps with 10 man tablebase files and an internet full of alpha-beta searchers, given the advance of hardware, it might be possible to prove the game theoretical outcome some day.

[Werewolf]

I suggest first to have a solving chess ranking list.

Engines get 10000 random positions from a pgn and need to decide for every position if it is a win for white or a draw or a win for black or they do not know.

The leader in the ranking list is an engine that identify correctly more positions in the list with a result.
Of course the leader may have bugs and if people can find a position that the leader decides wrong about it then it is a good reason to take the leader out of the list.

If an engine uses any kind of pruning beyond pure alpha-beta, then the output cannot be a proof of anything. Null move pruning, for instance, is unsound. Of course, it provides heuristic evidence, but that is not a proof.

Tablebase files were used in the proof for checkers. Perhaps with 10 man tablebase files and an internet full of alpha-beta searchers, given the advance of hardware, it might be possible to prove the game theoretical outcome some day.

Is it correct that alpha-beta reduces the necessary node count by approximately the square root of the nodes searched in mini-max alone?

[Dann Corbit]

I suggest first to have a solving chess ranking list.

Engines get 10000 random positions from a pgn and need to decide for every position if it is a win for white or a draw or a win for black or they do not know.

The leader in the ranking list is an engine that identify correctly more positions in the list with a result.
Of course the leader may have bugs and if people can find a position that the leader decides wrong about it then it is a good reason to take the leader out of the list.

If an engine uses any kind of pruning beyond pure alpha-beta, then the output cannot be a proof of anything. Null move pruning, for instance, is unsound. Of course, it provides heuristic evidence, but that is not a proof.

Tablebase files were used in the proof for checkers. Perhaps with 10 man tablebase files and an internet full of alpha-beta searchers, given the advance of hardware, it might be possible to prove the game theoretical outcome some day.

Is it correct that alpha-beta reduces the necessary node count by approximately the square root of the nodes searched in mini-max alone?

It assumes that move ordering is perfect, and in that case it is true. You examine something proportional to the square root of the nodes in the tree and get a perfect answer, the same as if you had done a pure mini-max. For this reason, alpha-beta is sound pruning. Today, engines have really good move ordering, so most of the time it is very close to a perfect alpha-beta search.

[syzygy]

I suggest first to have a solving chess ranking list.

Engines get 10000 random positions from a pgn and need to decide for every position if it is a win for white or a draw or a win for black or they do not know.

The leader in the ranking list is an engine that identify correctly more positions in the list with a result.
Of course the leader may have bugs and if people can find a position that the leader decides wrong about it then it is a good reason to take the leader out of the list.

If an engine uses any kind of pruning beyond pure alpha-beta, then the output cannot be a proof of anything. Null move pruning, for instance, is unsound. Of course, it provides heuristic evidence, but that is not a proof.

Tablebase files were used in the proof for checkers. Perhaps with 10 man tablebase files and an internet full of alpha-beta searchers, given the advance of hardware, it might be possible to prove the game theoretical outcome some day.

I fully agree that the output of an unsound searcher proves nothing, but the output can still be used to cross out unpromising lines. I remember from reading about the construction of the checkers proof that Chinook was used to "prove" certain positions to be a win or loss, e.g. if they evaluated to >+4 or <-4.

So with chess one could first try to build a "book" starting from a particular root position. If the root position then evaluates to, say, +2, it might be possible to look at the main lines and prove them one by one as winning with the help of tablebases and proof number search.

Doing for this for the starting position is hopeless, though, and I don't see improvements in hardware change this (unless there is a fundamental breakthrough in computing technology -- I don't think even quantum computers will make much of a difference here).

[syzygy]

I fully agree that the output of an unsound searcher proves nothing, but the output can still be used to cross out unpromising lines. I remember from reading about the construction of the checkers proof that Chinook was used to "prove" certain positions to be a win or loss, e.g. if they evaluated to >+4 or <-4.

Might have been this paper: https://icga.org/icga/journal/contents/ ... -01-08.pdf

4.2 Proof Solver (back end)

Pseudo-code for the back-end prover is shown in Figure 4. It is a novel combination of a traditional heuristic alpha-beta search and a proof search.
The (cheap) heuristic search value is used to determine whether the current position is relevant to the current proof threshold. The (expensive) proof search attempts to formally prove the result of the current position. The latter is only done if the former indicates it is needed.

Each back-end position is first searched by an alpha-beta searcher using a heuristic evaluation function and the endgame databases. The search is limited to 25 seconds, reaching a depth of 17 to 23 ply plus search extensions. The heuristic value returned is compared to the search threshold. Values outside the threshold range are considered as likely wins/losses by the proof tree manager. If the heuristic value is more than twice the size of the threshold, then no further processing is done; the formal proof search is postponed until later in the proof when we will have more confidence that we really need this result.

[Dann Corbit]

It sounds to me like they search it anyway, but wait until it has to be searched, so a sort of delay queue.