Chess will never be solved, here's why

Any 'particular type' of position is relatively rare.
The idea of forming tablebases without castling is a way to start off on the wrong foot.
Except for the fact that the people doing that project aren't trying to 'solve' chess anyway.
----------------------------------
The tablebases can be used for reference including for chess software.
They could decide to 'knock out' all kinds of stuff.
For example all positions that involve an excess of more than two extra of a piece type as in the initial position.
Like five white knights or more on the board. Four black queens.
Just knock all that stuff out to speed up the tablebase projects that aren't meant to solve chess and aren't going to.
As to how much that particular one would knock down the number of possible positions to be analyzed with the various tablebases from six to eight pieces - I haven't the foggiest. But its got to be a lot.
Plus noting it wouldn't be possible to have '3-excess' with three or four or five pieces on board anyway.
--------------------------------
Note that tygxc was talking a lot about 'knocking out' various kinds of positions but he messed it up with phrases like 'weakly solved'.
Much better is just 'reference tablebases' without any mention of 'solved' or 'strong' or weak'.
You wanted some terms Martin.
So there's one.
"Reference tablebases."
Instead of something corresponding to travelling across 1000 galaxies.

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

Tablebases are good. Strong solutions of a large number of positions (basic chess or chess with an N-move draw rule, but not a repetition draw rule).

Yes. They are good. But not for 'solving chess'. In any way.
They can't. Simple as that.
Nor can they nor do they prove any generalities about chess.
Nor do the ICCF games.

That's right. They solve easier analogs of chess.

They 'look for draws' and get them.
I wouldn't call that 'solve' though.
But E - maybe you will qualify 'analogs'.
Did you mean 'analogues'?

Actually they look for wins. The draws are the ones they don't find.

What is a "reference tablebase"? Is there any difference between that and a tablebase? I've googled it but found nothing relevant.

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

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

I agree with your first sentence at any rate.

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.

i know

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

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.

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.

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.

noooo he's back????

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

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.