Chess will never be solved, here's why

Sort:
Avatar of MARattigan
Dubrovnik-1950 wrote:
MARattigan wrote:
EndgameEnthusiast2357 wrote:

I wonder if it's possible for chess computers to be programmed with factual endgame knowledge added on to alpha-beta pruning. ...

That's what they do.

Usually by tweaking the alpha-beta static evaluations, bu SF for example, at least pre NNUE, allows the whole of specific endgames to be coded outside of alpha beta search.

Correct,

And they also probe the EGTB, and that is the most effective method of all.

Yes. Mind you SF still uses alpha beta with just the tablebase moves. It's a Syzygy tablebase and they probably don't want to finish off the game with something like this.

 
 

That said, the best SF with Syzygy will manage from that position is mate in 6. It would do it quicker under its own steam.

Avatar of MARattigan

Do you have any DTC tablebases? I'd really like a set of 3-4-5 men.

Avatar of EndgameEnthusiast2357
MARattigan wrote:
EndgameEnthusiast2357 wrote:

I wonder if it's possible for chess computers to be programmed with factual endgame knowledge added on to alpha-beta pruning. ...

That's what they do.

Usually by tweaking the alpha-beta static evaluations, but SF for example (at least pre NNUE, it may not still be true) allows the whole of specific endgames to be coded outside of alpha beta search.

Yeah I forgot KBPPKB would already be solved, even with 1 more pieces added in lol, so do engines prune the other depth searches once they stumble upon a desirable tablebase position in their current or "most deep/prioritized" search?

Avatar of crazedrat1000
Optimissed wrote:
crazedrat1000 wrote:
Elroch wrote:
crazedrat1000 wrote:
Dubrovnik-1950 wrote:

Can anyone tell us why this method is sloweAr?

And Yes I know the answer....

Why would I since it's something we've already discussed / had nothing to do with the conversation then or now...?

If you run leela on 2 separate distributed systems in 2 separate starting positions - i.e. what we're talking about - Amdahl's has nothing to say about that. It applies to one distributed system at a time.

Literally anything where you can separate tasks into large independent subtasks can be parallelised very well. You are implicitly thinking of an extreme version of that where you have two large separate tasks (I gave an approximate example).

EDIT: I misread "can" for "can't" here earlier, so my response didn't quite make sense here. Anyway...

I guess the advantage of leveraging multiple systems like this would be the modularity - i.e. it allows you to write the program in a way where it can run on a laptop, scale on one very large system, or be run on many separate grids if you want to scale up with the method you've described. But you don't have to deal with all the problems / extra acrobatics that forgoing synchronization entails. That's opening up a can of worms. It might not even work.

And you're relying on some search pruning function working efficiently enough to minimize transpositions i.e. duplicate work across nodes, but you're excluding viable paths in doing that.

I'd consider it a premature optimization until I'd exhausted other means. Like minimizing the reliance on synchronization, but not eliminating it.

There will probably also end up being alot of transpositions between midgames which we just aren't aware of.

Even if you just solved 1 line, like the Ruy Lopez, it'd be a noteworthy achievement but that problem alone is completely massive, you may have shaved off 3 or 4 orders of magnitude but you have many left to go.

It's just a more efficient method but it isn't going to save a significant amount of processing, compared with the entirety of the task. The magnitude of solving chess, in the way they refer to it (strong, brute force) is almost beyond comprehension. We probably wouldn't know when it was finished. I don't mean because we'd have died a trillion years before but more like the amount of processing required to tell us (whomever!) it was finished would add on a significant amount of processing. Saving the result would be next to impossible with current tech and at the end, it wouldn't amount to a deductive proof.

I've pointed this out before and I get the idea that it hasn't been comprehended. There's so much room for error and even disregarding that, for a proof, "solving chess" would, in any case, have to be performed again, in a different manner and only if the two results correlated would they be regarded as scientifically significant. All theory ultimately rests upon scientific proof which matches theoretical deduction, since all theory itself can only rest on scientific proof.

So far as I'm aware, nobody here has pointed out the above clearly.

I'm mainly interested in the methods. The idea if splitting up the problem is not my idea and not one I'm willing to defend. But I'm not necessarily interested in debating the problem in alot of detail, it's gone on for 961 pages at this point. I agree with your assessment - the scale is too big for current technology... and a design without a cache just doesn't work for a hard crack solution - not of any kind. Even just focusing on the Ruy Lopez, with a hard-crack solution you're going to have countless internal transpositions. You can't avoid using a centralized cache.

My sense is that Moore's law probably will not hold for much longer. And I remain skeptical that quantum computing is going to live up to people's expectations. 

Avatar of MARattigan

@EndgameEnthusiast2357

They should and usually would take the tablebase results into account if a search gets deep enough to reach a tablebase.

Avatar of MARattigan

Its distance to mate or conversion for chess without the 50 move rule. Nothing to do with Syzygy. I want to learn KQKNN and it would be easier using DTC tablebases than with Nalimov or Syzygy. But I don't know where to get a set.

Avatar of MARattigan

But they can also, and usually would, find lines into the endgame that are not forced. SF assigns a very high value to a Syzygy win, for example (around 200) and that will result in some pruning of other lines as @EndgameEnthusiast2357 suggests.

(It will know the draw result btw. only if both sides can force the draw and it will know any result only if it can complete the analysis of the relevant lines within its time control - SF doesn't otherwise generally do perfect play).

Avatar of EndgameEnthusiast2357

They should make some attempt to merge all different types of chess programs into one master one, for example, use the "neural net"/alpha-beta pruning from stockfish, the ability to solve obscure bizarre puzzle and studies from specifically designed engines like Crystal, as well as the supercomputer versions that can hit the hundreds of millions of positions per second brute force calculating range. Then add in the code from certain engines designed to better handle "closed positions" which many GMs say engines lack at. Then add in the tablebases, opening books, and even manually enter the solutions for tens of thousands of puzzles so that if it ends up in the starting position, it would trigger the engine to instantly realize that it's one of the puzzles and pull up the solution, without doing any pruning or searching whatsoever. Basically one master chess program combining all the different aspects that different engines use, into one single functional source code. Sounds like a good project for IBM to do.

Avatar of MARattigan

Ah yes, didn't notice the depth. I think your machine may be a bit faster than mine.

But the format isn't what you get back on SF info commands. The pv on those is a complete continuation and theres no tb value (but there is a tbhits value).

I thought you were running it in a GUI. How are you calling it?

Avatar of MARattigan

Oh of course. The dreaded editor.

Chessbase is what I meant by "your program", it reformats the stockfish info to present it.

The "= 0.11" top left is probably a Chessbase assessment of the position followed by Stockfish's evaluation (converted from centipawns). That illustrates that although it's hit the tablebase a number of times it doesn't yet know whether the position is drawn.

You might be interested in this btw.

Avatar of Elroch

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Avatar of MARattigan

Really rather difficult to know exactly what it means. There seems to be a general lack of knowledge about and you probably need to ask a developer or start delving into the code on GitHub. They started issuing documentation with SF16 (a bit late you might think). I haven't read it but you might try that. Don't hold out much hope though.

From inspection all the top 20 lines have acquired the next depth when you get them (you can ask it for 500 lines, but it won't do more than 20). The seldepth (second figure) varies slightly and can sometimes be lower, usually early in the search. Make of that what you will.

Avatar of MARattigan
Dubrovnik-1950 wrote:
Elroch wrote:

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Yes that is what it means.

And if you know how Type B chess engines work. And If you think that Stockfish is playing perfect chess, by pruning out ...% of the moves.

And not missing things, I got some ocean front property to sell you in Nevada.

But how can it have a deepest line shorter than the depth to which it's done a pretty thorough job? And what's a pretty thorough job anyway?

Avatar of playerafar
Dubrovnik-1950 wrote:
Elroch wrote:

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Yes that is what it means.

And if you know how Type B chess engines work. And If you think that Stockfish is playing perfect chess, by pruning out 99.9999999 ...% of the moves.

And not missing things, I got some ocean front property to sell you in Nevada.

Hahahhah. I don't think Elroch would make any mistakes like that.
tygxc ....
happy

Avatar of MARattigan
Dubrovnik-1950 wrote:
MARattigan wrote:
Dubrovnik-1950 wrote:
Elroch wrote:

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Yes that is what it means.

And if you know how Type B chess engines work. And If you think that Stockfish is playing perfect chess, by pruning out ...% of the moves.

And not missing things, I got some ocean front property to sell you in Nevada.

But how can it have a deepest line shorter than the depth to which it's done a pretty thorough job? And what's a pretty thorough job anyway?

Understanding Depth in Stockfish
Depth (d): The primary number displayed in Stockfish's output, indicating how many plies deep the search has gone.

Example: depth 20 means Stockfish has examined 20 plies (10 full moves).
Selective Depth (sometimes displayed separately): Stockfish uses pruning techniques (like alpha-beta pruning) to ignore less relevant moves, allowing it to evaluate some lines deeper than the main depth.

Example: depth 20, selective depth 32 means that in some branches, the engine looked 32 plies deep.
Iteration-Based Search: Stockfish uses an iterative deepening method, where it starts with a low depth (., 1 or 2 plies) and increases it progressively until time runs out or it reaches a predefined limit.
Influence on Evaluation: Higher depth generally leads to more accurate evaluations and better move choices because the engine has seen deeper tactical and positional consequences.
Practical Impact:

Blitz games: Lower depth (20–30) may be used due to time constraints.
Long games/analysis: Depths above 40 are common, with supercomputers or cloud-based analysis reaching 60+ plies.

But that seems to contradict what I said in my first sentence. Here's an example - look at depths 3-7 and 10.

And in your example, you might have a fast machine, but it hasn't done a full width search to 110 plys.

Avatar of MARattigan

But see my last sentence above. What depth?

Avatar of MARattigan

Sorry you're right I should have said 55 ply. But I still don't see what is your point. It still doesn't tell me what depth means.

No, I don't believe it means a full width search for each of the move options either. But I still don't know what it does mean.

Avatar of MARattigan

Yes, that sounds reasonable.

Still don't understand how seldepth comes out less though.

Avatar of Elroch
MARattigan wrote:
Dubrovnik-1950 wrote:
Elroch wrote:

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Yes that is what it means.

And if you know how Type B chess engines work. And If you think that Stockfish is playing perfect chess, by pruning out ...% of the moves.

And not missing things, I got some ocean front property to sell you in Nevada.

But how can it have a deepest line shorter than the depth to which it's done a pretty thorough job? And what's a pretty thorough job anyway?

Seems an unmotivated first question: 51 < 59 last time I checked. And "pretty thorough" means whatever the programmers chose to use to define the number. It's intuitive that you don't have very good knowledge of the tree to a certain depth when you first reach it, but that your understanding is asymptotic to perfect knowledge as you expand it. The smaller depth means something like the probability of the conclusions being invalidated by a new branch within the given depth has fallen below the threshold.

Avatar of MARattigan
Elroch wrote:
MARattigan wrote:
Dubrovnik-1950 wrote:
Elroch wrote:

Am I right in thinking "Depth: 51/59 " means deepest line 59 ply and a pretty thorough job to 51 ply? If not, what does it mean?

Yes that is what it means.

And if you know how Type B chess engines work. And If you think that Stockfish is playing perfect chess, by pruning out ...% of the moves.

And not missing things, I got some ocean front property to sell you in Nevada.

But how can it have a deepest line shorter than the depth to which it's done a pretty thorough job? And what's a pretty thorough job anyway?

Seems an unmotivated first question: 51 < 59 last time I checked. And "pretty thorough" means whatever the programmers chose to use to define the number. It's intuitive that you don't have very good knowledge of the tree to a certain depth when you first reach it, but that your understanding is asymptotic to perfect knowledge as you expand it. The smaller depth means something like the probability of the conclusions being invalidated by a new branch within the given depth has fallen below the threshold.

Motivation see #19234.

Revised question: What algorithm do the programmers chose to use to define the number and what is it the number of?

Haven't quite followed the procedure you have in mind to explain low seldepth. Could you give an example of how it would work?