Author: Robert Hyatt
Date: 07:47:25 07/17/04
Go up one level in this thread
On July 17, 2004 at 01:33:22, Volker Böhm wrote:
>On July 16, 2004 at 21:50:05, Robert Hyatt wrote:
>
>
>
>>On July 16, 2004 at 16:04:28, Volker Böhm wrote:
>>
>>>Hi,
>>>
>>>I am currently refining time control and want to use shorter time when a
>>>recapture is the only good move.
>>>I looked at crafty code to get some hints and found to "strange" piece of code.
>>>
>>>1.
>>>Crafty calls quiescense for all root moves and sort the moves according the
>>>quiescense value returned. If the best move is more than two pawns better than
>>>the second best move then it is an "easy-move" if a second condition holds true.
>>>I do not understand the second condition:
>>>it is:
>>>(Value[first_move] < PawnValue) || (IsRecapture(first_move). Why does crafty
>>>handle moves with value < PawnValue different here?
>>>
>>
>>Here is the actual code, I've inserted comments to make it clearer:
>>
>>/* if the first move has a value at least 2 pawns better than the second, then
>>the first move is sort of "obvious". The idea here is that there is exactly
>>_one_ good capture to play or else this "easy move" idea won't work. */
>>
>> if (sort_value[0] > sort_value[1] + 200 &&
>>
>>
>>/* the move has to be a recapture. IE the To square of the first root move has
>>to be the same as the To square for the last opponent move. If it isn't a
>>recapture, I don't trust it. For example try the position given later where an
>>older version of Cray Blitz thought that taking the knight was "easy" when it
>>was a blunder. */
>>
>> ((To(rmoves[0]) == To(last_opponent_move) &&
>>
>>
>>/* What I am capturing must also be the piece the opponent last moved. I am not
>>sure why this is there as it appears to be redundant. IE if To = To, then piece
>>must = piece. */
>>
>> Captured(rmoves[0]) == Piece(last_opponent_move)) ||
>
>
>I thought you wanted to exclude captures that are promotions.
That could be. The "easy" idea dates back something like 25 years for me, so
that may well be the hole I was plugging...
>
>
>>
>>
>>
>>
>> sort_value[0] < PAWN_VALUE))
>>
>>
>>/* This is the "non-recapture" exception. IE You take my knight at h2, I take
>>your knight at g7. The value says we are equal (score doesn't suggest we are
>>winning something which needs a full search to be sure it is safe.) */
>
>Then isn´t (abs(sort_value[0]) < PAWN_VALUE) better, (if you need a search if
>winning something why not if loosing something)?
I am simply trying to exclude captures that appear to win something to a shallow
search, but which lose to a deeper search, such as the CB vs Belle position I
posted below...
>
>>
>>
>>
>>
>> easy_move = 1;
>>
>>
>>Here is a test position to see what I mean:
>>
>>Came from the Cray Blitz vs Belle game at the 1981 ACM NACCC tournament:
>>
>>[D]5r1k/6p1/1n2Q2p/4p3/8/7P/PP4PK/R1B1q3 w - - 0 1
>>
>>
>>
>>>2.
>>>Another question on another aspect of time control. Crafty terminates search if
>>>time runs low and currently searching the first move of ply 1.
>>>I have implemented the opposit in Spike. I do not stop searching when currently
>>>searching the first move of ply 1 because I whant to prove that my current best
>>>move does not drop in value one depth later. If the value drops I continue
>>>searching with more time.
>>>Am I wrong?
>>
>>
>>
>>If the score is going to drop, it drops quickly. Fail lows are much faster to
>>search than normal or fail high positions. Here's the reason I do that.
>>Suppose my opponent takes a _long_ time to make a move, and I get deep into the
>>search and start a new iteration. Do I want to spend an hour to search the
>>first move, or should I give up quickly?
>>
>>
>
>It was the following comment that has missleaded me. There seems to be no code
>that fits to this comment. What you explaned above makes sense.
>
>Thanks Volker!
for (i = 0; i < n_root_moves; i++)
if (root_moves[i].status & 128)
ndone++;
if (ndone == 1)
abort = 1;
That does it. ndone == 1 if I am searching the _first_ move at ply=1... :)
>
>/*
> ----------------------------------------------------------
>| |
>| first, check to see if we are searching the first move |
>| at this depth. if so, and we run out of time, we can |
>| abort the search rather than waiting to complete this |
>| ply=1 move to see if it's better. |
>| |
> ----------------------------------------------------------
>*/
>
>>
>>
>>>
>>>Grettings and Thanks
>>>
>>>Volker
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.