@DiogenesDue
It appears to have done its calculations correctly when using the correct initial figures.
It doesn't always use the correct initial figures though which causes it to make errors that are obvious.
But then you can get it to correct itself.
Chess will never be solved, here's why
Sort:
Oct 18, 2024
0
#13062
DiogenesDue wrote:
EndgameEnthusiast2357 wrote:
Tablebases solves aren't exactly the same in that respect as not every single literal combination of that number of pieces or less has to be tested. For example if it was determined that 3 rooks can always beat 3 knights, then it is automatically known that 4+ rooks could beat the same number of knights. I once had a burning curiosity about this with queens vs knights, and I literally had stockfish play itself (not as accurate as a tablebase) in all 90 possible combinations of queens vs knights. I recorded the results in a table I may have posted in one of my earlier threads last year. At a certain point an increasing number of knights draws a fixed number of queens, and then after that, eventually turn into a win against the queens. Once say, 6 or 7 knights beat 2 queens, any higher number is also automatically a win. Once, say, 3 queens beat 4-5 knights, no higher number of queens even needs to be tested. And I found the drawing threshold is usually a fine line, meaning at a certain point adding one more pieces changes it from a loss to a draw, and adding 1 more after that bumps it up to a win. Very rarely are 2 different combinations consecutive draws. Then I did a little basic math and found that a ratio of 2.5 to 2.6 knights, is needed to hold a draw against x queens. Now obviously 15+ piece tablebases are impractical. But this logic and research method can be reduced down to smaller piece counts. For example a rook and knight usually beat 2 knights. Therefore adding any other pieces to the rook side doesn't need to be developed into a tablebase (basic engine analysis can take into account immediate forks/cramped positions..etc). That's what I was talking about with exchange-down conversion tablebases, knowing what piece combinations will almost always cancel out down to an already known tablebase/win draw. And such transitions/conversions can be handled by a conventional chess program like stockfish, and then the tablebases can take it from there after that point.
You are incorrect. Tablebases do indeed calculate out every combination, within their parameters (most exclude castling right now, for example). They cannot and do not make assumptions of wins based on material. If they did, you would not be able to to have a tablebase instantly give you back the correct path to the shortest win in a given situation. Anything you are talking about that shortcuts it this way would not be considered a tablebase.
The "rather obvious" K+5 Pieces vs King and maybe even some K + 4 vs King + 1 positions were omitted from 7 piece tablebase construction.
Oct 18, 2024
0
#13064
As for using Copilot and Chatgpt for whatever - I'm often finding that when one doesn't work at the beginning - the other does.
Maybe because one can modify the question.
Which won't work with the same one that was started with because its already started down a wrong road at the beginning.
Summarizing:
Using the average speed of solving 32 million positions per second for seven piece positions by the Syzygy project completing that particular project -
Copilot then stated a needed solving time of half a million trillion trillions of years to solve all 5 x 10⁴⁴ chess positions.
EndgameEnthusiast2357 wrote:
The "rather obvious" K+5 Pieces vs King and maybe even some K + 4 vs King + 1 positions were omitted from 7 piece tablebase construction.
I love how you make statements like this...remove the "maybe", or don't mention your suppositions.
If a given tablebase chooses to eliminate lone king positions, I guess that would be okay since they can calculate them on the fly (all should take less than 23 moves), and obviously a 17-man tablebase eliminating 16 on one side and the long king on the other makes some sense, but the point stands. Show me a single tablebase that eliminates K+R+N vs K+2N, which was your premise. There's a big difference between skipping easy to calculate positions versus skipping positions that might take 40+ moves to resolve. What exactly would they tell people that wanted them to prove the value of their project/product if there were a bunch of positions where the tablebase said "this is a win, but I can't show you how it is done or even how many moves it will take"?
You misunderstand. I never said they excluded KRNKNN. I said once such a tablebase is complete, KRNBKNN is unnecessary as it's obviously the same result if not more, than the former. It was analogous to my point that if X queens always beat Y knights, then X+1 queens also will. So you don't have to test X+2, X+3 vs the same number of knights (Y)..etc.
EndgameEnthusiast2357 wrote:
You misunderstand. I never said they excluded KRNKNN. I said once such a tablebase is complete, KRNBKNN is unnecessary as it's obviously the same result if not more, than the former. It was analogous to my point that if X queens always beat Y knights, then X+1 queens also will. So you don't have to test X+2, X+3 vs the same number of knights (Y)..etc.
Except that it is necessary, to show the results that tablebases are designed to show. If your premise is simply that If X queens wins then X+N queens also generally wins, then congrats, you have discovered something most chessplayers already know.
If, however, you want to prove conclusively that K+2Q always wins in every possible starting configuration against K+Q+B+N you are going to need a tablebase. Your suppositions based on your casual Stockfish analysis are not anywhere close to conclusive, and you ought to know better. What is the point of trying to narrow the number of knights down to 2.5 when the entire exercise is flawed from the beginning because you are using Stockfish? This is like your fantasy freeway systems...thought exercises that entertain you but are not useful.
If you want the analysis to be conclusive do the whole thing again using a tablebase directly, and guess what? You won't have to do some faulty math and come up with 2.5 knights, it will either be 2 or 3 knights, conclusively (because one answer that cannot possibly be correct is 2.5 knights 
...). Or, you could go over the Stockfish source with a fine tooth comb and determine absolutely that Stockfish uses its tablebase 100.00% of the time no matter what and satisfy yourself that their internal tablebase has not taken any shortcuts, but even then, why would you not just use a tablebase directly at that point?
I don't even want to ask you to expound on the "basic math" employed...
The math was simple. I made a table, queens on 1 axis and knights on the other. 10 knights and 9 queens are the max. I started each position in as fair and balanced way as possible (knights defending each other and near the king, queens on the other side, no immediate material loss..etc) For each combination I wrote the result in the specifc square. Once 4 knights beat 1 queen, "N" was filled in for every square on that row after it. This process repeated for the other pieces counts. I then took an average of the ratios where the result was a draw, in each row. Like 3/1, 5/2, 8/3..etc and it averaged out to 2.5-2.6 knights needed to hold against a queen.
Yes you technically need a tablebase to be 100% sure of every possible position with every possible piece combinations like your KQQKQNB example, but my point was that if a simplification is imminent (like an exchange of queens) a normal chess program might be enough to deal with that aspect of it, as well taking into account any position where there's a forced draw/stalemate/fortress incoming, or even a surprise win by the losing side if there's a mating net somehow. Otherwise a normal engine could calculate that and then once the inevitable simplification occurs (like trading queens), then the lower-piece tablebase can take over. But yes you are correct, a higher-piece tablebase is needed for 100% perfect certainty.
EndgameEnthusiast2357 wrote:
The math was simple. I made a table, queens on 1 axis and knights on the other. 10 knights and 9 queens are the max. I started each position in as fair and balanced way as possible (knights defending each other and near the king, queens on the other side, no immediate material loss..etc) For each combination I wrote the result in the specifc square. Once 4 knights beat 1 queen, "N" was filled in for every square on that row after it. This process repeated for the other pieces counts. I then took an average of the ratios where the result was a draw, in each row. Like 3/1, 5/2, 8/3..etc and it averaged out to 2.5-2.6 knights needed to hold against a queen.
Yes you technically need a tablebase to be 100% sure of every possible position with every possible piece combinations like your KQQKQNB example, but my point was that if a simplification is imminent (like an exchange of queens) a normal chess program might be enough to deal with that aspect of it, as well taking into account any position where there's a forced draw/stalemate/fortress incoming, or even a surprise win by the losing side if there's a mating net somehow. Otherwise a normal engine could calculate that and then once the inevitable simplification occurs (like trading queens), then the lower-piece tablebase can take over. But yes you are correct, a higher-piece tablebase is needed for 100% perfect certainty.
It's your time to spend.
Oct 19, 2024
0
#13070
EndgameEnthusiast2357 wrote:
Tablebases solves aren't exactly the same in that respect as not every single literal combination of that number of pieces or less has to be tested. For example if it was determined that 3 rooks can always beat 3 knights, then it is automatically known that 4+ rooks could beat the same number of knights. ...
There are no legal endgame classifications where one side can always beat the other.
Even if there were, your assertion sounds rather along the lines of, "if it is determined that a king and two knights cannot force a win against a lone king, then it is automatically known that a king and two knights cannot force a win against a king and a pawn".
Oct 19, 2024
0
#13071
Elroch wrote:
Yes, an odd comment. Most people would not think the number of legal positions would magically shrink if people tried to avoid repeating them in a game.
As I read it @EndgameEnthusiast2357 was referring to maximal game length rather than number of positions. Presumably in a game where repeating a 9.2.3 position was illegal but the 75 move rule was still in effect.
Oct 19, 2024
0
#13073
DiogenesDue wrote:
...
If, however, you want to prove conclusively that K+2Q always wins in every possible starting configuration against K+Q+B+N you are going to need a tablebase. ...
Not really, you just disprove it instead. There are no endgame classifications that contain any legal positions and are won for either side in every possible starting configuration (irrespective of whether FIDE basic or competition rules are used).
MARattigan wrote:
EndgameEnthusiast2357 wrote:
Tablebases solves aren't exactly the same in that respect as not every single literal combination of that number of pieces or less has to be tested. For example if it was determined that 3 rooks can always beat 3 knights, then it is automatically known that 4+ rooks could beat the same number of knights. ...
There are no legal endgame classifications where one side can always beat the other.
Even if there were, your assertion sounds rather along the lines of, "if it is determined that a king and two knights cannot force a win against a lone king, then it is automatically known that a king and two knights cannot force a win against a king and a pawn".
Knights vs a pawn is different. What I said normal chess programs could handle the exception positions where say, 3 knights do beat 4 rooks. Other pieces combinations don't have the quirk of 2 knights vs pawn(s) endgames.
MARattigan wrote:
DiogenesDue wrote:
...
If, however, you want to prove conclusively that K+2Q always wins in every possible starting configuration against K+Q+B+N you are going to need a tablebase. ...
Not really, you just disprove it instead. There are no endgame classifications that contain any legal positions and are won for either side in every possible starting configuration (irrespective of whether FIDE basic or competition rules are used).
Well, yes, I could have played the "what about this position setup where 9 queens don't matter because the other side has unstoppable mate in one..." card, but then I would have been met with "that's an unreasonable position that would never have been actually reached with best play". Which is very time consuming to disprove, and I don't want a lot of back and forth with constructed game scenarios when I can make the case without that.
I had it in my back pocket, though.
EndgameEnthusiast2357 wrote:
Knights vs a pawn is different. What I said normal chess programs could handle the exception positions where say, 3 knights do beat 4 rooks. Other pieces combinations don't have the quirk of 2 knights vs pawn(s) endgames.
You can construct scenarios all day where a bunch of knights win against a king + X amount of material...you simply place the king, then place the knights such that they drive the king inexorably in one path with checks, then place queens or other opponent pieces on the knight's checking squares...etc.
Oct 19, 2024
0
#13077
DiogenesDue wrote:
EndgameEnthusiast2357 wrote:
Knights vs a pawn is different. What I said normal chess programs could handle the exception positions where say, 3 knights do beat 4 rooks. Other pieces combinations don't have the quirk of 2 knights vs pawn(s) endgames.
You can construct scenarios all day where a bunch of knights win against a king + X amount of material...you simply place the king, then place the knights such that they drive the king inexorably in one path with checks, then place queens or other opponent pieces on the knight's checking squares...etc.
Well said.
The play doesn't necessarily have to be trivial, e.g. this Ottó Bláthy position from the KNNvKRRBPPPPPPPP ending.
White to play and mate in 50
White to play mate in 67:
Oct 20, 2024
0
#13080
That white to play and mate in 50 in Martin's post looks interesting.
I looked it over for legality to see how black's 8 pawns might get where they are and that part looks okay.
I'm thinking it begins with Nd2ch Ke1 Nxf3ch ...
but then there's a problem because after Kd1 what's white's next check?
So maybe white can afford some non-checking moves here and there.
Didn't peek yet.
I should add that I went back to Copilot and made it correct itself.
And it corrected to 4.84 quadrillion positions for 8 pieces.
Then I made it divide in the 32 million positions per second speed.
And it came up with 4.8 years to solve for 8 pieces.
Which is plausible since the project has been on it for 3 years already.
--------------------------
But one should not assume this means that 8 pieces will be solved in 1.8 years.
As more pieces are added - complexity increases.
So that 32 million positions solved per second might decrease substantially with time.
It could be looked into as to how the speed has varied so far as each piece is added.
But whatever the pattern - that doesn't mean it will or won't extrapolate.
Don't use LLMs for math. If it reports direct results it dug up, great. If you ask it to calculate something new, then use the "show me" link button on whatever LLM you are using to show the process step by step and go through it yourself by hand. LLMs can and will compare apples to oranges, list made-up results with real ones, etc.
Over time this should get better, but for now...yeah...don't use LLMs for math.