The unsolved chessproblem

Sort:
n9531l

I think what qualifies as the solution to a puzzle depends on the type of puzzle. If the puzzle is a challenge to construct a position in the ending R+B vs. N+N (White to move) which can be shown using tablebases, after best play by both sides, to end in a mate for White after more than 235 moves, what would you accept as a solution?

Arisktotle
n9531l schreef:

I think what qualifies as the solution to a puzzle depends on the type of puzzle. If the puzzle is a challenge to construct a position in the ending R+B vs. N+N (White to move) which can be shown using tablebases, after best play by both sides, to end in a mate for White after more than 235 moves, what would you accept as a solution?

By his own standards MARattigan would have to accept the EGTB reference as sufficient if it is accompanied by a correctness proof of the computerprograms which generated the tablebase and the one that is used as an interface to query it. From that we know with certainty that a solution exists against all defenses and how long it is (at most).

Generally, no author is required to provide the variations against all defenses, only the thematic ones. The rest is checked by engines, both by the author and the judges. Authors today do not even care to visually check suspicious looking variations since. as unthematic, these have no value for the composition anyway. The world has changed.

In the case of the problem at hand, providing just one longest DTM line is arguably enough, since the 'theme' is nothing else than having the longest DTM line en route to a world length record!

MARattigan
9531I wrote:
 
... If the puzzle is a challenge to construct a position in the ending R+B vs. N+N (White to move) which can be shown using tablebases, after best play by both sides, to end in a mate for White after more than 235 moves, what would you accept as a solution.
 
If the phrase "shown using tablebases" is to be taken to mean that the software used both to generate and query the tablebase can be assumed correct and it can be assumed that no hardware glitches have occured during the generation process nor will occur during the query process, and that the phrase "best play by both sides"  is to be taken as play meeting the objective assumed in the generation software (different for different types of tablebase, so the challenge is not fully defined), I would accept any position from the tablebase which is shown as a win for White with the distance to mate more than 235.
 
Under those assumptions the challenge you have stated takes no ingenuity. The ingenuity has already been used in constructing the tablebase, and for the most part is not related to chess but to achieving the construction within the constraints of available computing power.
 
I don't have any 6 man DTM ETGB's so I would have to download KRBKNN to answer the challenge, but as an example, Wilhelm gives the following as a longest mate in KRKBN (DTM) in a few minutes and all I have to do is make tea.
 
Your challenge differs from the one Moremover set himself in that there is an EGTB generally available for the pieces you describe. Both differ from the problem he set us. Different problems - different solutions.

Aristotle schreef

By his own standards MARattigan would have to accept the EGTB reference as sufficient if it is accompanied by a correctness proof of the computerprograms which generated the tablebase and the one that is used as an interface to query it. From that we know with certainty that a solution exists against all defenses and how long it is (at most).

No I wouldn't have to accept that, not even if it could be done (you would need a correctness proof of the operating system, language and link edit routines etc., etc. in addition to the generation routines).
 
This wouldn't eliminate the possibility of hardware errors.
 
Computers (not just programs) can and do make mistakes. (Indeed if I check any but the most trivial arithmetical result calculated by a computer, I invariably find it has made a mistake.)
 
What would be additionally needed for a proof of the correctness of a tablebase would be a print out or text file of all the steps used in the generation process - generally not possible within available computer resources. (And it might still take me some time to agree even if it were.)
 
Arisktotle schreef:
 
In the case of the problem at hand, providing just one longest DTM line is arguably enough, since the 'theme' is nothing else than having the longest DTM line en route to a world length record!

In the case of the problem posed by n9531I and making the assumptions stated in my first paragraph, zero lines would be enough. (I'm skiving off work again.)

If the challenge is to produce the record DTM line, then a single line would not, in itself, be enough. It would need also proof that the line given is indeed optimal play from the position shown. The OP's position contains 11 pieces, so this cannot currently come from an available EGTB even were you willing to accept EGTB pronouncements. 
 
Arisktotle
MARattigan schreef:

Aristotle schreef

By his own standards MARattigan would have to accept the EGTB reference as sufficient if it is accompanied by a correctness proof of the computerprograms which generated the tablebase and the one that is used as an interface to query it.

Marattigan schreef:

No I wouldn't have to accept that, not even if it could be done (you would need a correctness proof of the operating system, language and link edit routines etc., etc. in addition to the generation routines).
 
This wouldn't eliminate the possibility of hardware errors.
 
Computers (not just programs) can and do make mistakes. (Indeed if I check any but the most trivial arithmetical result calculated by a computer, I invariably find it has made a mistake.)
 
What would be additionally needed for a proof of the correctness of a tablebase would be a print out or text file of all the steps used in the generation process - generally not possible within available computer resources. (And it might still take me some time to agree even if it were.)
 

Nope, life don't work that way (it's no longer a chess issue but a life issue). By such an outrageous standard, no mathematical computer proof of any kind would have been delivered and no one will ever be delivered since every system set up to verify or trace errors in another system is subject to errors itself. But there is a more important fundamental flaw. The proof you do accept in the form of generated move series is subject to precisely the same errors. Who is going to check all these move series and who guarantees their brains make no mistakes? And if checked by computer programs instead, who says these programs are errorfree?

I said it is a life error, since life doesn't work that way. In fact, science philosophy and its methodologies do not work that way. On the road to knowledge we must  (as per Karl Popper) always accept the possibility that what we think to know is wrong. It doesn't matter. Having made fair effort (a dynamic standard) we are justified to declare certain conclusions to be knowlegde. This means we agree they are true for the time being. Depending on new developments and researchers finding contradictory evidence, the knowledge of one time may become unplugged and replaced by new 'certainties'. In 5 words: all knowledge is justified knowledge. That includes mathematical knowledge as soon as it reaches a degree of complexity that transcends our trust in errorfree verification (which is only opinion).

On a practical level you have zero justification to require a standard for proof for this problem that is not required for any other problem or endgame study. By adressing it here, you operate on a case level, whereas you should address it on a level of generalized discussion of proofs for chess problem solutions.

Arisktotle
MARattigan schreef:
 
Arisktotle schreef:
 
In the case of the problem at hand, providing just one longest DTM line is arguably enough, since the 'theme' is nothing else than having the longest DTM line en route to a world length record!

MARattigan schreef:

If the challenge is to produce the record DTM line, then a single line would not, in itself, be enough. It would need also proof that the line given is indeed optimal play from the position shown. The OP's position contains 11 pieces, so this cannot currently come from an available EGTB even were you willing to accept EGTB pronouncements. 
 

It is true that the OP must provide 'proof' in the range from his diagram until all 7-piece positions that could be derived from it. I assume this analysis is trivial - at least in comparison to the super jungle which reduces from 7 pieces to checkmate.

But again, he needs not provide all possible defenses in the reduction from 11 to 7 pieces - only the ones which by chess expertise judgement need to be researched. This is the same as for any other composition. Obviously it helps when engines like Stockfish are included in the verification process provided they are capable of accessing the 7-piece tablebase as well.

MARattigan

Arikstotle schreef:

By such an outrageous standard, no mathematical computer proof of any kind would have been delivered and no one will ever be delivered since every system set up to verify or trace errors in another system is subject to errors itself. But there is a more important fundamental flaw. The proof you do accept in the form of generated move series is subject to precisely the same errors. Who is going to check all these move series and who guarantees their brains make no mistakes?

A human readable proof delivered by a computer is perfectly acceptable (to the human reading it) provided he can see no flaw.

That would also be true, in principle, of the proof I said would be needed to verify the Oracle's pronouncements. Of course nobody would read it and in most cases it would be impossible to produce, which was really my point.

A human could write a rigorous proof that the following diagram is drawn in a short paragraph.

The proof via EGTB would go.

1) I do not contain this as a White win.

2) I do not contain this as a Black win.

3) I contain all White wins and black wins because + unproducible proof.

4) Therefore this is neither a White or Black win.

5) Therefore it is a draw.

and the sticking point is step 3 it will never be completed and understood. 

n9531l
MARattigan wrote:
 
I don't have any 6 man DTM ETGB's
 

You do have, if you have a browser that can connect to http://www.k4it.de/index.php?topic=egtb&lang=en.

MARattigan
n9531l wrote:
MARattigan wrote:
 
I don't have any 6 man DTM ETGB's
 

You do have, if you have a browser that can connect to http://www.k4it.de/index.php?topic=egtb&lang=en.

Thanks for the link. At the moment I still don't have any, though they obviously do. Should I be able to find a download somewhere on the site?

Arisktotle
MARattigan schreef:

A human readable proof delivered by a computer is perfectly acceptable (to the human reading it) provided he can see no flaw.

That would also be true, in principle, of the proof I said would be needed to verify the Oracle's pronouncements. Of course nobody would read it and in most cases it would be impossible to produce, which was really my point. 

"a human readable correctness proof delivered by a computer is perfectly acceptable (to the human reading it) providing he sees no flaw".

Do you see the symmetry? You think that reading the moves (and do not forget playing them) is easier than reading the proof? How is a reading and playing human going to verify the completeness and correctness of all variations offered? Don't you see that the massiveness is precisely the argument against certainty? In exactly the same way that massiveness is the issue in verifying the tablebase algorithms. If the proofs and the moves were leaner and meaner one would trust the simple proof just as easily as the printed variations provided.

This is a battle you can never win since every mathematician on the planet has decided against you. There are excellent proof programs today which e.g. recently solved the 4-colours problem. Not by analyzing 50,000 cases as 20 years ago but through a conceptual and logical framework (though I don't know the details). Well written computer programs in portable code are insensitive to errors in operating systems and hardware since their results can be verified in many different environments.

The point is that not accepting the contribution of a tablebase is a sign of nothing but stubborn persistence in an untenable viewpoint in the same class of the belief that the world is flat. You do know that this can maintained too, forever, by simply reinterpreting everything else that goes on on in the universe!?

Arisktotle
MARattigan schreef:

The proof via EGTB would go.

1) I do not contain this as a White win.

2) I do not contain this as a Black win.

3) I contain all White wins and black wins because + unproducible proof.

4) Therefore this is neither a White or Black win.

5) Therefore it is a draw.

and the sticking point is step 3 it will never be completed and understood. 

Chess is a finite game if you eliminate repetitions. This is OK since repetitions do not contribute to solving endgame problems. In a finite game only finite move series can be produced. The outcome of all these series is determinate. There are no question mark outcomes. It means that the result (win/lose/draw) for each position is determinate and resolvable by producing a finite series of moves (in variations). All solutions for all positions constitute finite proof for the results. This proof is not required for correctness, only the proof that a program will produce all the variations plus their outcomes.

What you write under 3 is therefore absolutely impossible unless your TB or proof program is wrong. 'Wrong' understood as 'incapable of producing a result which is producible' or 'unable to prove something that is provable'. In mathematics almost all proof problems come from infinity sets. This is not one of them and ending in mist is a sign of a wrong approach. 

One of the wrong approaches is to take a TB and try the prove it is correct. That is outright stupid. You go to the designers and ask for the program they used to produce the tablebase - and then you deliver a correctnessproof for that program. Most likely, your correctness proof would never even see the tablebase!

In short, I don't buy any stories lines about unresolvable issues in verifying the correctness of tablebases. I only see determinacy and finity. There are a lot of theses about 'halting' algorithms for computer programs by people like Church and Türing but I am not an expert on these. They could probably resolve the whole issue in 1 sentence.

MARattigan

Arikstotle wrote:

"a human readable correctness proof delivered by a computer is perfectly acceptable (to the human reading it) providing he sees no flaw".

Do you see the symmetry? You think that reading the moves (and do not forget playing them) is easier than reading the proof? How is a reading and playing human going to verify the completeness and correctness of all variations offered? Don't you see thatthe massiveness is precisely the argument against certainty? In exactly the same way that massiveness is the issue in verifying the tablebase algorithms. If the proofs and the moves were leaner and meaner one would trust the simple proof just as easily as the printed variations provided.

This is a battle you can never win since every mathematician on the planet has decided against you. There are excellent proof programs today which e.g. recently solved the 4-colours problem. Not by analyzing 50,000 cases as 20 years ago but through a conceptual and logical framework (though I don't know the details). Well written computer programs in portable code are insensitive to errors in operating systems and hardware since their results can be verified in many different environments.

The point is that not accepting the contribution of a tablebase is a sign of nothing but stubborn persistence in an untenable viewpoint in the same class of the belief that the world is flat. You do know that this can maintained too, forever, by simply reinterpreting everything else that goes on on in the universe!?

We're either talking at cross purposes or agreeing with each other; I'm not sure which.

I'm arguing against accepting EGTB pronouncements as proof because of the impractibility of a human grasping any proof that the pronouncements are correct i.e. because of the masiveness and because one cannot rule out machine glitches. A proof that the generating code is correct doesn't necessarily translate to a correct EGTB.

The generating code may in practice be incorrect anyway. A DTC EGTB has been produced on the incorrect assumption that a conversion to a won simpler ending by either side would always be via a pawn promotion or capture by that side. It gives plausible but incorrect results. And a quote from http://galen.metapath.org/egtb50/

The most common is to add a "DTZ50" metric, which counts down to an irreversible move. Many implementations, however, do not handle it correctly because they fail to account for which player made the last irreversible move, and so can be off by a half-move. 

You say, "If the proofs and the moves were leaner and meaner one would trust the simple proof just as easily as the printed variations provided". I'm not sure what you mean here. The simple proof would presumably refer to the one paragraph proof I said a human would produce for the diagram I gave (which would probably contain no move sequences) - what are the printed variations you refer to?

Twenty years ago the mathematical fraternity was certainly divided on the question of whether the four colour theorem had been proved for exactly the same reason that I would question the validity of accepting an EGTB pronouncement as proved. I understand that with computer assistance a proof has now been produced that runs to only 60,000 lines or so, which is no doubt manageable (but looks very tedious for the most part). The relevant point here is that the computer assistance is not relevant. A proof is a proof.

Well written computer programs in portable code are insensitive to errors in operating systems and hardware since their results can be verified in many different environments. 

Having spent much of my life in debugging system problems I would advise readers at home to take this with a large pinch of salt. Carry on downloading the Java updates.

(I would imagine in any case that the Lomonosov generation programs would have been Assembler and probably non portable.)  

MARattigan

Aristotle wrote:

What you write under 3 is therefore absolutely impossible unless your TB or proof program is wrong. 'Wrong' understood as 'incapable of producing a result which is producible' or 'unable to prove something that is provable'. In mathematics almost all proof problems come from infinity sets. This is not one of them and ending in mist is a sign of a wrong approach. 

The proof is unproducible in 3 not because it's infinite but because it will not fit into the storage available on a current supercomputer.  

Aristotle wrote:

You go to the designers and ask for the program they used to produce the tablebase - and then you deliver a correctnessproof for that program.

 

But how does your correctness proof take account of possible hardware glitches during the generation? The generation program can in this case be perfectly correct, but the generated table not.

MARattigan
[COMMENT DELETED]
AbhiTheGr8
Moremover wrote:

Who can find the correct FIRST EIGHT MOVES of my unsolved chess problem at youtube.com :

http://www.youtube.com/watch?v=JnLiwJ3qe_M

write here at chess.com or at youtube.com

kindly regards from Germany by moremover

Mail : lutz.neweklowsky@gmx.de

Fax : 0049-721-841095

It is unavailable.

MARattigan

AbhiTheGr8 wrote:

  • It is unavailable.

But the other one Moremover gives is available:

https://www.youtube.com/watch?v=dhCni05-w_c

Now that's what I call a composer!

jhanson666

To the man who said anyone who can compose a longer mate I can the game my friend played at a recent tounoment was 5 hours long and was like 300 moves its ridiculous really

Arisktotle
MARattigan schreef:

The proof is unproducible in 3 not because it's infinite but because it will not fit into the storage available on a current supercomputer.  

Aristotle wrote:

You go to the designers and ask for the program they used to produce the tablebase - and then you deliver a correctnessproof for that program. 

But how does your correctness proof take account of possible hardware glitches during the generation? The generation program can in this case be perfectly correct, but the generated table not.

I already addressed the latter issue. Every computer program is, or can be written in portable code. That permits its (re)execution in multiple environments sufficient to guarantee the elimination of 'glitch results'. Edit: in the 'lost' post I wrote that the generator program should be rewritten in portable code as well for convenience; but it probably already was before it was optimized. And obviously, any generator program should be run and rerun in as many as possible different environments portable or not. Preferably two teams should develop the same program on different platforms and compare the generated TBs. But hasn't that been done already?

i cannot respond to step 3 in detail since I am not sure what you are trying to do. It seems to me you trying to validate the TB itself which is a highly inefficient approach to correctness.

But the essential meta point is that knowledge need not correspond to perfection. For instance when testing study variations, the judges accept an evaluation score of something like 2.5 (don't know the exact number) as sufficient to declare a win. Presumably the standard for direct mates is much higher (more like 99.9999%) but for the long moremovers they will certainly settle for less than 100%. More important is to keep an open mind towards anyone claiming to beat the tablebase. On chess.com we have n9531l for that job. He is always willing to defend the tablebase side on such challenges, even when it takes years! Wink

Arisktotle
MARattigan schreef:

We're either talking at cross purposes or agreeing with each other; I'm not sure which.

I'm arguing against accepting EGTB pronouncements as proof because of the impractibility of a human grasping any proof that the pronouncements are correct i.e. because of the masiveness and because one cannot rule out machine glitches. A proof that the generating code is correct doesn't necessarily translate to a correct EGTB.

The generating code may in practice be incorrect anyway. A DTC EGTB has been produced on the incorrect assumption that a conversion to a won simpler ending by either side would always be via a pawn promotion or capture by that side. It gives plausible but incorrect results. And a quote from http://galen.metapath.org/egtb50/

The most common is to add a "DTZ50" metric, which counts down to an irreversible move. Many implementations, however, do not handle it correctly because they fail to account for which player made the last irreversible move, and so can be off by a half-move. 

You say, "If the proofs and the moves were leaner and meaner one would trust the simple proof just as easily as the printed variations provided". I'm not sure what you mean here. The simple proof would presumably refer to the one paragraph proof I said a human would produce for the diagram I gave (which would probably contain no move sequences) - what are the printed variations you refer to?

Twenty years ago the mathematical fraternity was certainly divided on the question of whether the four colour theorem had been proved for exactly the same reason that I would question the validity of accepting an EGTB pronouncement as proved. I understand that with computer assistance a proof has now been produced that runs to only 60,000 lines or so, which is no doubt manageable (but looks very tedious for the most part). The relevant point here is that the computer assistance is not relevant. A proof is a proof.

Having spent much of my life in debugging system problems I would advise readers at home to take this with a large pinch of salt. Carry on downloading the Java updates.

(I would imagine in any case that the Lomonosov generation programs would have been Assembler and probably non portable.)  

The reply to this post got lost when sending it. Therefore the previous reply is incomplete. I will try to rewrite it later if there is time.

One issue: I still fare on your last weeks statement that the Tablebases are complete and correct (apart from unkowns). If there are known errors - especially the ones that may affect the WR-problem (without pawns in its 7-piece tail) then obviously my arguments go to waste.The same would be true of the TB-construction process is known to have been sloppy, the programmer was drunk most of the time or no testting of any kind was done before it's release. But that is part of the obvious methodological jusitification, right?

MARattigan

Arikstotle wrote:

One issue: I still fare on your last weeks statement that the Tablebases are complete and correct (apart from unkowns). If there are known errors - especially the ones that may affect the WR-problem (without pawns in its 7-piece tail) then obviously my arguments go to waste. 

...

So far as I know there are no errors in the Nalimov DTM tables, the Syzygy DTZ50 tables or the Lomonosov tables. 

The Syzygy generator is freely available. I think the others aren't (I could be wrong).

If a generator is run on different machines and the results have the same mda count, then for practical purposes at least one can eliminate the possibility of errors in the result due to gamma ray bursts or drunken operators. I would guess this has actually been done several times over for the Syzygy databases and I know that there were post generation checks (maybe not complete) on DTM tables produced by different methods.

I don't know anything about the quality assurance measures used for the Lomonosov 7 man tables. 

My guess would be that there are zero errors in the commonly accessible versions of the above databases, but I'm not an expert in this area.

(This assumes that the Syzygy DTZ50 tablebases do not suffer from the flaw I quoted earlier regarding DTZ50 tablebases. I think I would have noticed something on the internet were this not the case.)  

MARattigan
icyviper wrote:

dat philosophy overload.... feels bad, man.

@Arikstotle: Sounds like we're being asked to leave the stage. Could be a good idea.