Author: Eugene Nalimov
Date: 14:28:44 08/04/99
Go up one level in this thread
There *are* violations of 50 moves rule in 5-man TBs: for example, KBNKN. There are mates in 107 (WTM). There are no pawns, and the longest winnable minor TB for KBNKN is KBNK. As longest mate in KBNK is 33 moves, it's obvious that there are mates in KBNKN that violate 50 moves rule. I will not be surprised if there are other cases (e.g. KBNKP, or KBPKN). Correct solution would be to store pair (DTM, DT(C or pawn move)) in the TBs themselves. Note that that will roughly double amount of memory necessary for TBs, that is why I did not implemented it for 5-man TBs. With 5-man TBs such exceptions are rare. Eugene 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. >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.