Author: Uri Blass
Date: 06:45:35 11/06/01
Go up one level in this thread
On November 06, 2001 at 09:35:13, José Carlos wrote: >On November 06, 2001 at 07:23:07, Gian-Carlo Pascutto wrote: > >>On November 06, 2001 at 07:18:29, Leen Ammeraal wrote: >> >>>My program sees that black deserves a very high score, >>>derived from the egtb, but fails to make the trivial >>>move 1. ... g1Q because it does not find an entry >>>for the resulting position in the egtb, and because >>>the computed score after this promotion move >>>is lower than the egtb score retrieved after the >>>move Rg3, so the latter move is made and the >>>game results in a draw instead of in a win for >>>black. Has anyone encountered similar problems? >>>It seems to me that for any egtb file with >>>pawns, there should be a corresponding file >>>for the case that one of the pawns has turned >>>into a queen. If not, the result may be >>>completely wrong, as in the above example. >>>Leen >> >>This is wellknown. >> >>A possible solution is to turn off egtb's if you are in an egtb >>position and you note that the distance to mate does not shorten >>anymore. >> >>-- >>GCP > > I don't understand. If the draw-by-repetition and draw-by-50-moves-rule tests >are done correctly, this is, _before_ probing, the program will surely move the >rook stupidly during 50 moves. Then it will see the draw, and chose another >move. I don't see how the program can accept the draw here. > > José C. It is possible that the program's move is only the 99 ply with no conversion so the program looks at the tablebases and does not consider it as a draw and the draw is in the 100th ply that the program does not consider because it looks on the tablebases. It is also possible that in the 100th ply the program finds that conversion does not win(there is another win by tablebases but it is a draw by the 50 move rule). Uri
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.