Chess will never be solved, here's why

The thread has lasted through all kinds of things.
At least two have tried hard to make it about them.
One of them - not so badly.
He's still here. He's not going away.
I haven't 'invented' anything. I have no red telephone.
People get to express themselves here.
You don't have to do what I'm suggesting Martin.
You know that.
You also know that I'm maintaining that a 'solution' that doesn't include castling can never be a 'strong' solution. And then 'weak' ceases to be valid too.
Its not meant to be 'annoying' but if you insist on being annoyed you know I can't stop you from being annoyed.

"You also know that I'm maintaining that a 'solution' that doesn't include castling can never be a 'strong' solution. And then 'weak' ceases to be valid too."
'Nobody' is going to understand that?
From Dio earlier:
"Weak and strong do not apply so let's not muddy up that terminology any more than Tygxc et al already muck them up. Tablebases that skip castling and en passant are incomplete"
Incomplete. Another better word.
Dio also 'informed' about gallium arsenide.
And yes Elroch had already begun to say (I think) that Moore's Law wasn't really continuing to hold anyway.
One of my aims: interfere with 'nodes per second'.

Can you tell me this forum is guerilla warfare?

What are we supposed to be talking again because in these late pages I rarely see anything related to the topic

There's different 'degrees of disagreement'.
Many 'like a good argument'.
If its too tame doesn't work. If its too wild doesn't work.

This is straight of guerilla warfare right now

Great post right through!
"and it went under while waiting for Moore's Law to flatten out for silicon"
"I suspect once we hit about 10-12 pieces, there will be a call to go back and start parallel efforts to catch up and complete the tablebases."
Me too. But I suspect I won't live to see that.
But there might be alternative projects too.
Tablebases generating checkmate positions (mate in zero) for Any legal number of pieces on board including 32.
A beginning of a project to produce an 'imperfect solution' of chess.

A solution that doesn't include castling can be neither a weak or a strong solution of either basic or competition rules chess because the starting position includes castling rights. You don't need to invent your own terms to state that. It follows directly from the jargon.

A solution that doesn't include castling can perfectly well be a weak or strong solution of a position in either version of chess that includes no castling rights.

Whether it is or not is a fact that follows directly from the definitions, not a subjective feeling that the words "weak" and "strong" may induce in different contributors.

(As for, "And then 'weak' ceases to be valid too", I don't understand it. Maybe somebody does.)

The argument here about the 'jargon' terms seems to be one where some may have forgotten what exactly they were arguing about

"A solution that doesn't include castling can perfectly well be a weak or strong solution of a position in either version of chess that includes no castling rights."
One can wade throught that?
'Version of chess'.
'Perfectly'.
Well at least you used 'perfectly'.
Should we be doing versions of chess that don't include other moves too and present them as 'perfectly strong'?
-----------------------
If 'strong' is invalid - and it Definitely looks invalid without castling - then 'weak' as 'opposite of strong' gets extra-invalid.
------------------
But Dio (I'm confident I've got this right but not certain) already indicated that tablebases that don't include en passant and castling are 'incomplete'.
And also that the tablebases so far should soon be revised and properly completed.
Incomplete. Good word.

Having already pointed out that the Syzygy tablebases incorporate the en passant rule throughout, it is worth adding a point about the omission of castling rights. Fortunately, not only is this (relatively) computationally cheap to include, it can be efficiently added afterwards. The easiest way is to add a new tablebase file for each relevant class of material - i.e. at least one side has at least one rook - but to only include positions where at least one of the sides has castling rights (a very major restriction of the locations of the pieces, making it more like the size of a tablebase with 2 fewer pieces).

Note that all of these classes of positions are "upstream" of the ones that already exist, in that you can get to an old file (specific material, no castling rights) from one of the new files (specific material, with some castling rights) by a legal move (one that leaves the position with no remaining castling rights) but not in the other direction (you can never gain castling rights by a legal move - they are there even when there are pieces blocking them at present).

The computational cost of these additional files is small compared to the rest - a king has to be on a specific one of 64 squares and a rook has to be in one of two squares, so there are thousands of times fewer positions than for the same material without castling rights. There are also no files for positions without rooks, of course.

While the files would be generated separately, it would be possible (but unnecessary) to merge them with the file with the same material without any castling rights, with a technical change to the code for how the file is used. This would mean fewer files and less switching between them.

So, now you know what you need to do, @playerafar! You can make Syzygy "strong".

Elroch remember what you kept/keep saying to tygxc about probability and completeness and rigor. An idea. To remember.
I'm reminding you that the tablebases so far are incomplete.
No matter how much you repeat indications of 'that can be fixed easily'.
Get it yet?
No? How long before that is 'solved'?

Your comments have been a bit odd recently.

The situation has changed.

It was badly phrased. It should have read.

A solution that doesn't include castling can perfectly well be a weak or strong solution of a position that includes no castling rights in either version of chess.

Hopefully you can understand that.

"'Perfectly'." as in the well known phrase, "perfectly well" - not intended to have any reference to perfect play.

"Should we be doing versions of chess that don't include other moves too and present them as 'perfectly strong'?"

No, that would probably be too far off topic.

@Elroch
What I'm showing to you is that people on the same general side of an issue can disagree. Openly.
We don't have to do things like Washi and T-guy do them.
'Its our team against your team. Our city will kick your city's A-- !'
I say we do better than that. We do.
Its a fact.
Defining what we disagree on:
Better ways to go at the subject.

Returning to the topic of using computation efficiently, a clever thing would be to prioritise those tablebases that are more likely to turn up AND where positions are not trivial. The lopsided tablebases are only really of theoretical interest, because how far it is to mate doesn't matter much when you have a couple of extra pieces - it's just a position where the result is (with high confidence) known. This could be a big deal for practical application - I think generating a 9 piece tablebase of classes of positions that are likely to not have clear evaluations could be as cheap as generating the whole 8 piece tablebase.

As I edited my earlier comment after @playerafar responded to the one line version, here is the rest of it:

Let me point out that a tablebase is fundamentally just a class of positions that are strongly solved. There is nothing special about the number of pieces - this is just a way of dividing up the set of all positions. So what the current Syzygy tablebase does is provide a set of 38,176,306,877,748,245 positions that are strongly solved, so that if they happen to appear in the analysis tree their value is known.

What you (@playerafar) are saying is that you are radically unhappy that this is not a slightly larger class of positions (well under 0.1% bigger). I would prefer that it was too, but it really isn't a big deal. ALMOST ALL chess positions are NOT included in the tablebase and for practical purposes what matters is what turns up.

You can be sure that a few positions with more pieces and no castling rights would be more useful than the ones with fewer pieces and castling rights, because castling rights are only rarely there in the ending. Even where they do remain, the engine will get information from the tablebase for every line where castling rights are lost later, exponentially reducing the analysis needed.

So it's not a high priority. I have no doubt that Ronald de Man and Bojun Guo spotted this years ago when they made their design decisions.

Sometimes.

Sometimes it's fundamentally just a class of positions that are weakly solved.

You conceded that your initial attempt was badly phrased.
Good. Progress.
But your 2nd prototype - I don't think its a big improvement.
And I have no red telephone.
You probably won't try this ...
but try to word it without 'weak' or 'strong' because 'version of chess' is already 'weak'. Very.
Very weak.
But - put in a nice way. Refers to the post. Not the member.
-----------------------
What would actually be 'strong'?
32 piece tablebase including all possible castling situations and en passants and solving all possible ensuing positions including noting all winning positions with 'checkmate in x moves and precisely the value of x in each case'.
That would be strong. Even if it 'skips' 3fold and the 50 move rules.
Why would it be strong? Because it encompasses the moves of the pieces.
------------------------------------------------
Are there ways it could be even stronger?
Yes - and not just those two extra rules.
A stronger solution would also indicate if there's a forced stalemate and minimum number of moves to that.
Minimum number of moves to a forced draw because of insufficient material.
There could even be embellishments:
Like - minimum number of moves to mate if helpmates are factored in too. 
And helpdraws.
----------------------------
Note that if there's a forced checkmate in a minimum number of moves - that minimum could be lower if there's 'help'. Happens constantly in games.