Author: Robert Hyatt
Date: 21:26:46 02/08/99
Go up one level in this thread
On February 08, 1999 at 17:18:29, Eugene Nalimov wrote: >On February 08, 1999 at 16:25:33, Robert Hyatt wrote: > >>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... >> > >But can the draw happen not on the 1st opponent move, >but on the 2nd? > >Eugene yes it can... this is a problem, but I don't think it can happen in this case again, because It should continue to work toward the shallowest mate. My case was a real bug that happened. But with repetitions and 50-move issues, it can be a problem... the point here is that for 50 move problems it would choose the best mate that pushes the pawn. Ditto for repetition, hopefully, although there is likely still a big hole there... Probably would be better, once _in_ a tablebase position, to only probe at the 'tips'?? Messy stuff this non-path database info. :) > >> >>>> >>>> >>>>> >>>>> 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.