Author: Robert Hyatt
Date: 17:29:15 08/04/99
Go up one level in this thread
On August 04, 1999 at 17:17:24, Ricardo Gibert wrote: >On August 04, 1999 at 16:45:32, Robert Hyatt wrote: > >>On August 04, 1999 at 12:29:08, Ricardo Gibert wrote: >> >>>On August 04, 1999 at 09:19:56, Robert Hyatt wrote: >>> >>>>On August 03, 1999 at 23:13:13, Ricardo Gibert wrote: >>>> >>>>>On August 03, 1999 at 21:54:23, Robert Hyatt wrote: >>>>> >>>>>>On August 03, 1999 at 15:34:54, Ricardo Gibert wrote: >>>>>> >>>>>>>On August 03, 1999 at 14:28:04, Robert Hyatt wrote: >>>>>>> >>>>>>>>On August 03, 1999 at 10:28:25, Ricardo Gibert wrote: >>>>>>>> >>>>>>>>>On August 03, 1999 at 09:00:33, Robert Hyatt wrote: >>>>>>>>> >>>>>>>>>>On August 03, 1999 at 04:45:07, Ricardo Gibert wrote: >>>>>>>>>> >>>>>>>>>>>On August 03, 1999 at 04:32:27, Bruce Moreland wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>On August 02, 1999 at 22:47:14, Ricardo Gibert wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>Your post is a little ambiguous. Are you saying Nalimov EGTB is a shortest mate >>>>>>>>>>>>>EGTB for all the 5 man endings? How would the tables be generated? >>>>>>>>>>>>> >>>>>>>>>>>>>I would be surprised if all the endings covered by the Nalimov EGTB are of the >>>>>>>>>>>>>shortest mate variety. I would also be disappointed for the reason indicated. >>>>>>>>>>>>>Some endings (other than KQKR which a computer program can win in about 34 >>>>>>>>>>>>>moves) would be "impossible" to win using such a TB due to the 50 move rule. >>>>>>>>>>>> >>>>>>>>>>>>I would be suprised if the Nalimov tables are *not* distance to mate. The only >>>>>>>>>>>>publicly available distance to conversion tables that I know of are the Thompson >>>>>>>>>>>>tables. >>>>>>>>>>> >>>>>>>>>>>Shortest mate EGTB also has the defect of possibly concluding that an ending is >>>>>>>>>>>drawn due to the 50 move when it is actually winning. By the way, I think this >>>>>>>>>>>issue can be cleared up by noting that "distance to mate" is not necessarily the >>>>>>>>>>>same as "shortest mate". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>first, 50 move draw is _not_ included. How could it be? Because you have >>>>>>>>>>_no_ idea what position you will enter the database at... >>>>>>>>>> >>>>>>>>>>and distance to mate _is_ "shortest distance to mate" absolutely... >>>>>>>>>> >>>>>>>>>Then this means the EGTB will prefer a mate in 51 without pawns moves or >>>>>>>>>captures to a mate in 52 with a pawn move or capture before the 50 move rule >>>>>>>>>kicks in. It will draw winning positions. Undesirable and unnecessary. >>>>>>>>>Fortunately rare. >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>yes... but this is a problem no matter what. Because the tablebase is just >>>>>>>>a file that is indexed by piece location, and it provides mated-in-N, draw, or >>>>>>>>mate-in-N. It has _no_ idea about prior positions and what might have >>>>>>>>transpired before reaching this position. It can't even tell if this position >>>>>>>>is a successor of another position in this file, or if it was reached via a >>>>>>>>capture with a zero 50-move counter. >>>>>>> >>>>>>>prior positions are irrelevant. >>>>>>> >>>>>> >>>>>>you are wrong here. I play move A, then move B (which unmakes move A), >>>>>>then move A again, then move B again, and now I probe the table, and it >>>>>>says if you play move X you win the rook in 4 moves. Unfortunately, >>>>>>a couple of moves before you win the rook, you play move A again and >>>>>>the position is repeated and the game ends as a draw. >>>>> >>>>>The EGTBs hits should be "part" of the eval. A tool. You catch 3 fold reps the >>>>>same way you always do. For example, distance to mate also would have this >>>>>"problem". What difference does it make if you find mate or win of a rook? >>>> >>>>> >>>>>Besides, after you play A the 1st time, you probe and find move X to win the >>>>>rook. No draw. >>>>> >>>> >>>> >>>>this is going in circles. This was _my_ argument. then _you_ pointed out >>>>you were talking about doing a probe _after_ an adjournament. And there, the >>>>problem is going to come up and there is no solution for it. >>>> >>>>If my program plays the whole game, this will _never_ be a problem. If you >>>>give it a position to play after someone else has played a bunch of moves, >>>>then this wil never work properly. >>>> >>> >>>It will be a problem regardless (unless you also provide the game score) of how >>>you do it. "My way" addresses the 50-move problem. >>>> >> >> >>I don't think it is a problem at all, at present, as I don't know of any 5 >>piece files that have more than 50 moves without a pawn move or capture. > >KNNKP > >But I am talking about producing an adjournment analysis where I need to avoid >the 50 move rule due to my sub-optimal play. > >Example: I adjourn in a KQKR ending and I need to make a winning capture or mate >in 5 moves to win and avoid the 50 move rule draw. A mate in 6 won't do it. "My >way" just tells me the answer. It returns whatever is quicker, the win of the >rook or mate. It won't deal with 3 fold repetition gracefully, but we are >talking about the 50 move rule here. your way also may return 'draw' as there may be _no_ moves that lead to a mate in 5 or less, even though every move leads to a mate in 6 or more... > >>However, the 6 piece endings are a serious problem in this regard. Someone >>might probe the tablebase files for the deepest mates and then follow the PV >>(by looking at the scores as you step forward) to see if there is a PV in the >>thing that has more than 50 non-capture/non-pawn-move moves in it. Lewis >>Stiller has already proven that this is a problem in 6 piece files. >> >>Many years ago I did an experiment to see if this was 'fixable' by building a >>KBN vs K database... but I added one new rule, if all three pieces don't get >>moved within a 10-move window, the game is a draw. I ended up storing a >>'DTM' score _and_ a "conversion" score... where a conversion occurred everytime >>the 'third' piece was moved to reset the counter. It seemed to work, with the >>only problem being 'database entry'. IE when you first hit the database, the >>DTC might be (say) 7, yet it might be that more than 3 moves have been played >>in the real game (again, assuming starting from a position rather than from the >>beginning of the game). To fix this, I started out by simply playing the move >>or moves that would get the 10-move-rule counter back to zero, and _then_ using >>the DTM/DTC values as you suggest. And it worked except for a few oddball cases >>that were not really fixable... it might be that the only moves that reset the >>10-move-rule counter lead to tablebase draws because you have already played >>ineffectively before you started hitting the databases (remember, these were >>positions that the program was just given, not positions it had been playing >>from the beginning.) >> >>Whether all of the issues of 'adjourned' analysis can be resolved or not is >>a question. My initial thought is "no". Because it is definitely possible to >>be in a won position, but by fiddling around before using the tablebases, you >>have reached a position that will run afoul of the 50-move rule before winning, >>and there are no options to win a piece (ie KBN vs K, where you have played 30 >>moves already, and the resulting position is a mate in > 20 no matter what you >>do, and there is nothing to win or no pawn to push to reset the counter.) >> >>Sticky problem... >> >> >> >> >>>> >>>>>> >>>>>>If you don't have state information in the database, there is _no_ way >>>>>>to probe it and ask about such things.. because it says you can capture >>>>>>a piece in 29 moves, but how many _prior_ positions of yours do you repeat >>>>>>before doing so? >>>>>> >>>>>>This is an old discussion. There are _many_ problems here... >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>deep mates are going to be a problem in 6 piece files, no doubt about it. It >>>>>>>>would be interesting to see if there are already violations of this in the 5 >>>>>>>>piece files... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>And yes, the tables do suffer from the possible problem that you mentioned, >>>>>>>>>>>>although this should be extremely rare in practice. >>>>>>>>>>>> >>>>>>>>>>>>bruce
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.