Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Time control question - don´t understand crafty´s logic

Author: Volker Böhm

Date: 22:33:22 07/16/04

Go up one level in this thread


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.


>
>
>
>
>          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)?

>
>
>
>
> 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!

/*
 ----------------------------------------------------------
|                                                          |
|   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.