Chess will never be solved, here's why

Sort:
MARattigan
playerafar wrote:
MARattigan wrote:

Don't have too much problem with "weakly solved". I read the Wiki definition.

He didn't refer to generating tablebases in the same context, but how could anyone use "Reference tablebases" to distinguish between weak and strong solutions?

Because its not 'solving'.
Its 'reference tablebases'.

What is not solving? And again what is a "reference tablebase"? You appeared to be proposing the phrase as a replacement for the jargon, "weakly solved".

playerafar
MARattigan wrote:
playerafar wrote:
MARattigan wrote:

Don't have too much problem with "weakly solved". I read the Wiki definition.

He didn't refer to generating tablebases in the same context, but how could anyone use "Reference tablebases" to distinguish between weak and strong solutions?

Because its not 'solving'.
Its 'reference tablebases'.

What is not solving? And again what is a "reference tablebase"?

You know what all four words mean.
No red telephone needed.
Its okay Martin.
Everything's going to be all right in the land of chess.
You don't like 'reference tablebases'?
Oh dear. Well there are worse things in the world.
But the conversation lately - tells me how the 'real conversation' might have been had the whole two years with major improvements over what actually happened.
And I think tygxc senses it. Is why he's silent for now.
Waiting for his 'opening'.

MARattigan

I agree with your first sentence at any rate.

Elroch

All of the information for a strong solution is in a (ruleset specific) complete tablebase, and a strong solution is one easy step from the sort of information a tablebase interface typically displays.

To explain that last part, to get the key information about all the legal moves displayed in a tablebase, you need to look at what the strong solution says about all of the positions that can be legally reached from a position.

(It may be that the information you see in a tablebase is mostly generated on the fly, and each position has the minimum information stored. How they achieve the compression needed for Syzygy is a mystery to me, but on the fly generation of information is a way to save a lot of storage.

mpaetz

Hello Opti. It's nice to see chess.com has let you back in.

EndgameEnthusiast2357

We have endgame tablebases for the most extremely complex endgames and we have very deep analysis of hundreds of mainline openings. It's the middlegame that is the astronomically vast middle link to solving chess. Even if tablebases increased to 10 or 12 pieces in the far future and opening books were enhanced to all be 25+ moves deep, it's the middlegame that's just pure calculation and tactics and positional strategy and a mix of everything, nothing computers could just numbercrunch or follow a preprogrammed book.

playerafar

EE is wrong of course.
Something isn't an 'endgame' just because there's 8 or fewer pieces on board.
If just the heavy pieces come off early - there's still up to 26 men on board.
So saying 'its the middlegame' is immediately invalid.

MARattigan
Elroch wrote:

All of the information for a strong solution is in a (ruleset specific) complete tablebase, and a strong solution is one easy step from the sort of information a tablebase interface typically displays.

To explain that last part, to get the key information about all the legal moves displayed in a tablebase, you need to look at what the strong solution says about all of the positions that can be legally reached from a position.

(It may be that the information you see in a tablebase is mostly generated on the fly, and each position has the minimum information stored. How they achieve the compression needed for Syzygy is a mystery to me, but on the fly generation of information is a way to save a lot of storage.

Fascinating.

Can you post the algorithm for the "easy step"?

From skimming the CCRL posts the compression techniques proposed appeared to be based on Huffman codes. There are often similar series of moves occurring in mates with translations that are not necessarily board symmetries. You could possibly find more info by looking at the CCRL threads.

I thought the information in Syzygy was complete except for e.p. positions which need a very limited amount of on the fly analysis, but I can't swear to it.

TumoKonnin
Optimissed wrote:
playerafar wrote:

Martin - tygxc hasn't posted for four days here.
Maybe that's a record for him.
And maybe one of your posts or somebody else's posts 'did something to him'.
Causing him to take a long overdue 'vacation' from his 'mission' here.

He would be better not to post here at all. I have not agreed with tygxc's arguments much of the time but I do agree with his synthesis, even if he cannot communicate it in a way that many others find understandable.

One thing is clear ... that the people arguing against tygxc are no more informed than he is. Perhaps they are informed in different rather than in better ways. Since the positions of all those arguing against him are on a weak foundation, the differences here boil down to differences in approach and in opinion.

Having already discussed the subject with some here (but not wishing to do so again, since although they are undoubtedly extremely brilliant people, able to percieve, in milliseconds, every nuance encompassed by the subject matter, they are perhaps not quite capable of realising that it's obvious why they're really here) I'll leave it at that.

noooo he's back????

playerafar

@TumoKonnin 
That isn't clear yet.
But the discussion continued in any case.
Whether technically or in a general way.
Computer projects regarding chess and chess software and discussions of what is known and not known about the game and relevant math and science all seem to be very appropriate topics on a website like this.

Elroch
MARattigan wrote:
Elroch wrote:

All of the information for a strong solution is in a (ruleset specific) complete tablebase, and a strong solution is one easy step from the sort of information a tablebase interface typically displays.

To explain that last part, to get the key information about all the legal moves displayed in a tablebase, you need to look at what the strong solution says about all of the positions that can be legally reached from a position.

(It may be that the information you see in a tablebase is mostly generated on the fly, and each position has the minimum information stored. How they achieve the compression needed for Syzygy is a mystery to me, but on the fly generation of information is a way to save a lot of storage.

Fascinating.

Can you post the algorithm for the "easy step"?

From skimming the CCRL posts the compression techniques proposed appeared to be based on Huffman codes. There are often similar series of moves occurring in mates with translations that are not necessarily board symmetries. You could possibly find more info by looking at the CCRL threads.

I thought the information in Syzygy was complete except for e.p. positions which need a very limited amount of on the fly analysis, but I can't swear to it.

What I was musing was that the tablebase would only store information about one move in each position (a fastest win/slowest loss/any draw one in the W/L/D cases), and that the information for all the moves in a position can be derived on the server by looking at the new positions reached. I am thinking of the human interface here - the one for engines is probably not interested in anything but the value of the position (given ply count). (While there are certainly some issues for suboptimal play and repetitions, I'd guess they don't cause many problems).

If I am right it would be an elementary design efficiency for a tablebase designer, so obvious they wouldn't mention it.

I can't see why e.p. is any different. It's a legal move that leads to another tablebase position.

EndgameEnthusiast2357
playerafar wrote:

EE is wrong of course.
Something isn't an 'endgame' just because there's 8 or fewer pieces on board.
If just the heavy pieces come off early - there's still up to 26 men on board.
So saying 'its the middlegame' is immediately invalid.

That's not what I meant by endgame. I meant endgame referring to a combination if pieces left that doesn't involve anymore transformations/conversions to simpler combinations, such as 2 bishops vs knight, queen vs rook, queen + knight vs knight + bishop + rook, 2 knights vs pawn, rook + knight vs 2 knights...etc, some of which can take hundreds of moves to win with perfect play. Middlegames might have multiple endgame that it can end up going into, there might be thousands of possible piece combination endgames that cam result from the middlegame. By "middlegame" I literally just meant the phase between opening book moves and where tablebases are needed.

Elroch

The definition of an endgame is not that precise.

EndgameEnthusiast2357

You're right, and even a couple of those "precise move" tablebase endgames, technically involve a trivial capture at some point which is a transformation, but I was just trying to distinguish between "middlegame" and the point at which it comes down to pure geometry and exact moves matter in one specific type of endgame. Pawnless endgames might be a better distinction since no new pieces can appear from promotion. It comes down to the pure geometry of the remaining pieces themselves, such as 2 bishops vs knight. The most complex endgame, Queen + Knight vs Rook + Bishop + Knight has no pawns and can take over 500 moves to force a win. In the middlegame it's more vague strategies in calculation such as "putting pressure", "forcing opponents position to become cramped", "having a good pawn structure", "dominating the center", "heading toward the side their king is on"...etc, not exact calculation from a tablebase.

playerafar

@Elroch - I've also considered that 'one move' thing. In multiple ways.
In theory - each advancing tablebase could then only have to 'deal' with a one ply depth to get to the next already-established tablebase position?
No because that would only work with captures.
----------------------------------
There are so many ways of classifying positions.
And it seems that if a 'one ply deep' method of approaching tablebase generation could be applied - then there would not have been so much struggling over a period of years to proceed from six pieces to seven pieces?
No. Because if that idea could have 'fixed things' - then it would have.
--------------------------------
Idea: (I'm confident they applied this obvious idea) - and that is - as they proceed backwards from just two Kings on the board - they use a 'hierarchy' of positions to create starting points.
And even a hierarchy of hierarchies.
So for example to go from six pieces to seven pieces - perhaps they used both material and position hierarchies something like this:
----------------------------
First add one pawn on its original square. Both colours.
Start with edge-pawns (fewer options)
Then go to pawn placed on its third rank of the board.
But with adding one pawn at least four 'attribute variables' begin to develop.
Yes 'attribute variables' is probably bad english.
But 'criteria' wouldn't seem to fit here.
You're a statistician so you would know the correct statistical term or terms for the following:
-----------------------------------
1) the pawn does or does not have a double pawn move available. Note that a pawn on its home square might not have that option available.
2) the pawn can or cannot move at all.
3) the pawn can or cannot capture at all.
4) the pawn can or cannot promote at the time.
and then 'attributes' (yes might be the wrong word.)
white or black pawn.
who is on move.
-------------------------
After adding a single pawn tablebase (one ply deep) is generated -
then adding a single knight Instead could be done (or maybe was/is done)
starting with a knight in each of the corner squares (fewest options)
then a N on an edge non-corner square with max 3 squares available.
then an edge-knight with 4 such squares available.
Note a knight at g2 and b2 and b7 and g7 still only has four squares available but is then an interior-knight.
Then knight that has six options and then finally 8 options. (no 7's or 5's but there is a '3').
-------------------
and then moving on up towards a Queen instead added at the end.
-------------------------------
basic 'demarcation': Is at least one capture available on the board?
Should that be another 'adding' priority?
It seems yes.
Because otherwise the start of the higher tablebase doesn't connect to the previous one!
For project purposes that seems almost more important than whose move it is !!
And does the capture have to be available to the side on move?
In the first hierarchy yes.
In the second - its the other side.

Elroch
playerafar wrote:

@Elroch - I've also considered that 'one move' thing. In multiple ways.
In theory - each advancing tablebase could then only have to 'deal' with a one ply depth to get to the next already-established tablebase position?
No because that would only work with captures.

It's important to distinguish between GENERATION of a tablebase and ACCESSING a tablebase.

The generation process consists of iteratively generating all the positions that will reach a win for one side with perfect play. Here "perfect play" has the stronger meaning that the winner always wins as fast as possible (assuming perfect defense) and the loser always gets mated as slowly as possible (assuming perfect attack). Rather than me trying to describe it, here is the description selected by the wiki authors, from Tim Krabbe.

playerafar

@Elroch
from your post:
"The generation process consists of iteratively generating all the positions that will reach a win for one side with perfect play."
But first you would have to generate positions in the first place.
I'm thinking that that is the primary process - getting to 'win' is a kind of 'gravy'.
But yes that Wiki link you posted points to a nice article.
In full form: https://en.wikipedia.org/wiki/Endgame_tablebase#Step_2:_Evaluating_positions_using_retrograde_analysis<br<; a=""> />-----------------------------
--------------------
Also my question about 'attribute variables'.
But you don't have to answer of course. Questions aren't thunder.
----------------------
Regarding 'iteratively' that pertained to some of the other points in my post.
Note that Alpha Zero was prevailing for a while because it was an improvement in 'prioritizing calculations'.
And also adding - that the forum subject of 'solved' pertains to the game itself - not just computer projects.
In other words the forum subject pertains to how players go at the game - as opposed to how chess software goes at it.
Its a much broader topic than might appear.
Note that the Opening Poster referred to this very point in his opening post.
And he referred to it Heavily.
-------------------------------
Example: Stronger players will and do tell weaker players when coaching how to adjust to speed chess: 'Look at checks and captures first.'
In other words prioritize primary tactics.
But why wouldn't one do that with slower chess too?
----------------------------------
Connection: in tablebase projects - prioritize positions that contain at least one capture option. And start with positions that have just one.
Because that is the revolving door between levels of tablebases.
Is 'aesthetic effect' the right phrase to describe this next point?
In considering computer projects to solve chess - the entire game is considered in a kind of overview. An overview that computers would perhaps not be capable of.

Elroch
playerafar wrote:

@Elroch
from your post:
"The generation process consists of iteratively generating all the positions that will reach a win for one side with perfect play."
But first you would have to generate positions in the first place.

Good point. It's very easy to generate all the positions with given material, ignoring any inconsistencies. But for efficiency you need to filter out most of the illegal ones. (In some cases it would be too difficult to filter out all of the illegal ones). So that is the first step - generate a set of positions that have a good chance of being legal (and definitely include all those that are legal, with some specified material). 

I'm thinking that that is the primary process - getting to 'win' is a kind of 'gravy'.
But yes that Wiki link you posted points to a nice article.
In full form: https://en.wikipedia.org/wiki/Endgame_tablebase#Step_2:_Evaluating_positions_using_retrograde_analysis<br<; a=""> />

It's worth noting that the steps are very asymmetical. To generate all positions that are mate in N from all positions that are mated in N-1, you just find the ones that can legally get to them.

By contrast, to find the positions that are mated in N from those that are mate in N, you first generate the positions that can legally get to the latter, but then have to check all of the other legal moves to see if any of them fails to do better.

Also, positions can accumulate a lot of information from different steps before they are evaluated. At a given stage, you can know that some of the moves from a position get mated in various numbers of moves, but all you know is that you can avoid mate for some maximum number of moves. There may be another move that draws or wins, to be discovered at a later stage.

Hope my musings about whatever understanding I have gleaned is not too boring. If so, ignore it!

playerafar

@Elroch of course your musings are not boring.
Boredom is usually the fault of the bored person.
Like being blocked is usually the fault of the blocked person.
--------------------
You stated that its 'easy' to generate all positions with whatever number of pieces - if I have that right.
That part is obvious and incidental though.
The point is: what positions to prioritize - or concentrate on first.
Then you mentioned about 'mate in x' or whatever.
Which isn't my point.
Because that almost relates to circular reasoning.
Because in the initial stages you don't know what those positions are.
Hence my suggestion: start with positions where there's an obvious 'feature' or 'certain attribute' or 'meets criteria'.
For example - generate all positions where there's a capture available - but only one capture.
So there's a two way door between such positions and their more basic tablebases. The most minimal door.
------------------
You could argue that the project people have covered all that.
That they've considered all the 'vicissitudes' in this project to counter the 'viscious' number of legal positions with each number of men on the board.
---------------
the opening poster here apparently closed his chess.com account two days after posting the opening post.
He had been with chess.com just 11 days. Since Jan. 5th 2022.
Posted and started this forum Jan. 16th 2022.
Closed his chess.com account Jan. 18th 2022.
Idea: he closed his account because of the reaction he got in this forum ... ??

playerafar

I was just looking at the posts that were made those first three days in this forum.
Saw this excerpt from Martin:
"There is no 50 move rule, 75 move rule, 3 fold repetition rule or 5 fold repetition rule in the FIDE basic rules of chess. Those rules now apply only to games covered by competition rules. The 50 move rule and 3 fold repetition rule were removed from the basic rules in 2017, the other two were never in. Prior to removal the draws had to be claimed anyway so games of any length were permissible."
'competition rules'.
'basic rules'.
Terminology again.
Yes - Martin probably stated more than once in what situations FIDE 'competition rules' apply and what situations they don't.
If I saw it - I forgot.
But does that mean people entering the forum would know?
Does it matter?
Short answer: slightly.
------------------------
Anyway idea - after three days of postings the forum took a kind of trajectory the opening poster had never intended and he closed his account.
Does that part matter?
No.
But what about what he intended?
Does that have any significance?
Maybe. Something to do with time investment.