Author: Robert Hyatt
Date: 13:45:32 08/04/99
Go up one level in this thread
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. 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.