Author: José Carlos
Date: 14:30:23 11/06/01
Go up one level in this thread
On November 06, 2001 at 16:21:13, Uri Blass wrote: >On November 06, 2001 at 10:31:05, José Carlos wrote: > >>On November 06, 2001 at 09:45:35, Uri Blass wrote: >> >>>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 >> >> Ok, I get it. After _my_ move I get a tb hit when it's ply 99. Then my >>opponent moves and it's ply 100, so it's a draw after my opponent's move. >>Correct. >> Bob gives a solution in other post, but there's another possibility. When you >>get a tb hit, check if it is ply 99. If it is, anything exept checkmate is a >>draw. Well, you lose some time checking the 100 ply counter, but it's a tiny >>time compared to the tb probe. >> >> José C. > >It is not so simple > >The next possible situation can also happen > >It is ply 97 you play a move that is a win by tablebases. >The opponent reply with check so you cannot play a conversion in the next move >and inspite of the fact that the position is a tablebase win you get a draw by >the 50 move rule. > >Uri Correct again. But this leads to a much more difficult problem to prevent: the case when, having all tablebases, ply 100 is closer than tb checkmate. Tb closer mate can happen without moving pawns of making captures, and then the program choses that shortest mate and finally draws, when it could have moved a pawn, delaying the mate 10 moves later, but avoiding the 50 moves rule. I guess this is impossible to prevent with todays tb's... Maybe with this idea: if the # of moves to mate is bigger than moves to 50-rule and you can move a pawn or make a capture, and then tb return a mate in < 50, go for that instead of the shortest. Would this work or am I missing anything? José C.
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.