Chess will never be solved, here's why

I was wrong, Wikipedia says they were included a few years later, making 7 piece tablebases complete.

Complete apart from castling. (Depending on what is meant by "complete" - no tablebase attempts to cover positions that incorporate repeated positions considered the same as specified in 9.2.3.)

Wrong thread

wrong pixie po-leece-man to be worried abt op-admin stuff. so stay outta it.

"du99bious elaboration"

Didn't know that

But Lola now you're trying to be police-lady.
Lol!
Did you see EE admitting just now he 'was' wrong?
I better quote it before he deletes it.

Now quoted before EE can delete it.
With Martin then reminding EE that EE continues to be wrong because of the fact that 7 piece tablebases fail to include castling move possibilities in their analysis.
EE stubbing his toe again but Martin right there.

Castling isn't included because it is dependent on whether the rook involved has moved at all since the beginning of the game. Tablebases work backward from checkmated positions, and the only way to determine if the rook or king has moved before being in the castling position, is to go all the way back to the beginning of the game. It's not something programmable into a tablebase that way. En passant too but maybe not to the same extent due to the unilateral movement of pawns. Castling could become relevant in positions like this:

Too late EE.
You were already caught in your mistake and quoted too.

Your post was wrong EE. Is wrong. And you know its wrong.
The 7 piece is not complete and you were told.
You're wrong a lot of the time about many things.
Normally I'd just post around somebody like you -
But lets see if you're deleting your posts here too.
I don't intend to get stuck with a lot of consecutives.

In constructing a tablebase it's not necessary to know when a position that has lost castling rights lost them, only that it has lost them. (Which can result also from king moves.) There is no significant difference in producing tablebases with castling rights from producing tablebases without castling rights. I think the omission comes about because producing tablebases with castling rights for each possible combination of castling rights would result in a very significant increase in the number of tables required for a given number of men. (But as @Elroch mentioned earlier, the extra tables would be substantially smaller than the child tables without castling rights.)

E.p. positions have to be (and are) taken into account in constructing tablebases with one or more pawns on each side.

Hi Martin - regarding tablebases that include castling -
the actual variations and analysis would differ slightly.
It would affect far under 5% of positions (positions that have at least one king and at least one of its rooks not having moved at all and still at home (arbitrarily set) (more like far under 1%) but not those positions where its arbitrated that castling has become illegal.
Point: there has to be a compelling reason as to why they skipped castling.
-------------------------
Conjectures: They left out particular factors as to previous issues that brought each position to where it is.
What they did include: (if I've got it right)
1) whose move it is
2) en passant possibilities
3) positions where it would be too difficult to 'analyze back' multiple plies to make sure it could have got there legally.
They included those three kinds of issue because they only had to go back one move (ply) so therefore it couldn't slow down the software much.
Excluded: 
1) Illegal positions such as a King in check from a pawn on its home square.
Again - only requires one-move-back consideration. One ply that is.
2) Repetition of position considerations. That's more than one ply back.
3) 50 move rule considerations. Same reason.
-----------------------
What did they do with K+2N versus King? Guess - they didn't analyze much unless the two knights side has checkmate on the move available.
The same with various 'book draws' positions.
----------------------
But leaving out castling leaves the 7 piece tablebases incomplete.
Castling is a legal move of the game unlike repetition of positions and 50 moves factors. Should captures be left out too?
Leaving out castling compromises the 8 piece tablebases.
That one will be incomplete too.
Whoever could take trillions of years to try to maintain that 'doesn't matter' though.

But Lola now you're trying to be police-lady.

ur 5th in...so u need2sh**up. im 4th in. 3rd in (dodo due) was just making trubble. and im holding him in hellacheck. and besides ?...he doesnt need ur smooshy help. he can handle his own. so there.

Lola you want to shut people up here?
Good luck with that.
And yes Dio can handle his own which means you just kind of contradicted yourself.
You're holding Dio in 'hellacheck'?
I doubt that.
Dio is hard on people who spam and troll.
Its a fact.
Its also a good thing.
-----------------------
Do the people who spam and troll 'need your help' Lola?
And you want 'back and forth' right?
Hey there's always the forum subject.
Its actually a great subject with lots of potential.
And very appropriate on this website.

That's a great post.
Very efficient and to the point.

DTZ move tablebases shouldn't be bothered with either. The 50 move rule shouldn't exist. Tablebases should generate the best move based on the position, not what move ensures a pawn will be moved at move 49.

The 50 move does and should exist.
For obvious reasons.
That doesn't mean it should be included in tablebase projects though.
Especially now.
--------------------
Such projects need starting points.
And prototypes.
And very high speed with the software and hardware.
Somehow for whatever reasons - including castling was and is going to be just too slowing down of the software.
Without knowing the exact reasons is it hard to conjecture in a general way as to why?
No.
Computer software is like 'spahetti code'.
If adding something to a program is going to be like unravelling spaghetti ...
well that could take longer than the project itself.
----------------
So instead - with any big software project what happens is glitches and deficits and issues.
And to fix them they'll often need a whole new version and some 'starting over'.
Maybe they'll have the castling issue fixed before they start on a 9 piece tablebase.
As for 50 moves and repetition of positions - those would be pretty easy with three pieces on board.
Or four pieces.
When and how does it get prohibitive?
Same issue probably. Computer software 'spaghetti code'.

No I'm sorry 50 moves for each side is way too low in alot of endgames, and it also leaves no room for human error in even very common endgames. There's even a 2 rooks + pawn vs queen position where it's mate in 200 and the first pawn move isn't until move 119. So even 100 moves wouldn't be enough. There is no need for any move limit in practical play. Just have the tournament director step in and declare the game a draw if it's going on so long it's holding up the schedule. Even online, just have some kind of automatic timer that will immediately declare a blitz game a draw after say 15-20 mins, if both sides are abusing the increments in drawish positions. If a 5+2 game is going on for a half hour, circuit breakers kick in and declare the game a draw if it's been going on for 500 random moves.

You can play chess without being in a tournament or online. Just play FIDE basic rules chess.

EE - you can be 'sorry' about your illogic all you want to be.
Forever. You have permission.
I didn't read past your 'sorry'.

The 50 move rule is absolutely necessary.
And evolved over hundreds of years.
Because of something called ... necessity.
Its like the touch move rule in over the board rated tournament chess.
Necessary.
Rules. Worked out and accepted over hundreds of years by millions of people.
Whoever can be 'sorry' all he wants to be.
Reminds me of the guy who used to begin with he's 'afraid'.
Same kind of nonsense.