Author: Robert Hyatt
Date: 13:25:23 02/08/99
Go up one level in this thread
On February 08, 1999 at 11:18:50, José de Jesús García Ruvalcaba wrote: >On February 07, 1999 at 18:30:17, Robert Hyatt wrote: > >>On February 07, 1999 at 13:12:01, José de Jesús García Ruvalcaba wrote: >> >>> >>>Was crafty using the full 3+2 five men tablebases? >> >>yes... >> >> >>>If the position after 100...Kc4 is a mate in 70 moves, then the position after >>>101.Qe2+ should allow black a move which is a mate in at most 69 moves. But this >>>position appeared *twice* before in the game. I wonder why crafty did not go for >>>the mate in 69 *before*. >> >> >>the problem is that at the point where it screwed up, it had a _real_ mate >>in 73, or a bogus mate in 70 (bogus because it was a draw before the mate >>could be played). So it went for the mate in 70 because the bug didn't let >>it detect that the next opponent move would be a 3-fold repetition. >> > > I see that crafty would never give up the h-pawn to reach a drawn QP vs Q >ending. So I assume that the position after 96. Qxh5+ is won for black. > I do not understand why, in a tablebase position, crafty allowed the same >position to appear twice (however, I understand why it allowed the third >repetition now). If crafty is in a won tablebase position, the distance to mate >should decrease every move. > that was the 'bug' I reported. in my search, I tried all moves at ply=1, but at ply=2 did the tablebase probe _before_ trying any opponent moves. And since I did this, I made a move that led to the shortest possible mate, but also led to a position where when the opponent moved, it repeated the position for the third time. Now, I _always_ search all moves at the first 2 plies and only probe at depth=3 and beyond, to be _sure_ I know that after crafty _and_ the opponent make a move, the position is not drawn by repetition or 50 move rule counter... >> >> >>> >>> Is it possible to have a queue of tablebase positions which need to be scored >>>waiting for the harddisk to respond? >> >>not really. Because when I do a probe, I _know_ I will get a result. So >>the search will definitely terminate here, with win/lose/draw scores. But I >>can't really go on until I know which... because of alpha/beta.... >> > >I see, the score is needed for the cutoffs. I realized that after giving it some >thought at home. > >> >> >>>Currently there are no faster drives available, but there will... >> >>Certainly, although I doubt we are going to see much below 5ms for the >>access time. There is still 'inertia' to overcome. But it wouldn't matter >>if it was down to 1ms... because compare a 1ms disk read to a 2ns instruction >>cycle time in a 500mhz processor... a difference of _one million_ that will >>only get worse, not better...
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.