Author: rasjid chan
Date: 01:54:18 12/28/03
Go up one level in this thread
On December 27, 2003 at 13:01:33, rasjid chan wrote: nt >I think I did not misunderstand Ed's article. He mentioned one decides >at the horizon whether to call QS :- > > Trick_Two gave about a 5-8% speed-up, I don't quite remember exactly, >its thought behind: if the score is already 9.00 above BETA don't bother to >do QS, it won't matter, the score is way too good, its pseudo code: > if (own_king_was_in_check_before_make_move) -> return FALSE (too risky) > if (opponent_can_promote_the_next_ply) -> return FALSE (too risky) > if (SCORE-900 > BETA) -> return TRUE > else return FALSE > >Tony Wertens's mention about the placement of eval() may be incorrect. > >The above shows the alpha and beta is for the side on move depth == 0 >in accordance with the normal situation. Rebel fails high only on conditions. >His "if score <= alpha return score" should mean returning from the search() >which means fail low (This is still too drastic). > >My suspicion now is that QS may not be as simple as beginning chess >programmers may think. There may not be a standard or simple way to implement >it the way I accepted it in the past. > >I can now understand the QS of TSCP. It had to call QS when >score < beta simply because its eval() has only pure positional aspects. >Consider the simple situation where a pawn captures a queen and in the >next ply eval() is down 900. QS had to be called as most often >there is an off-setting equal capture. Failing high when score >= beta >is normal as it is a null move concept. The side on move can decide >to curtail the line of exchanges and fails high. > >I can now think of one situation when we need not fail high >when score >= beta, ie when the oppn side can promote next ply (with >a pawn that is not blocked or is a capture) as this is not within the >line of capture echanges. This may be an improvement but then we must >not set alpha = score and accept the score after QS and ignore current >node eval() as a score after QS is "more reliable". > >Another thing is someone mentioned SEE and QS. I don't fully understand SEE, >but off-the-hat I think it is a very bad and expensive piece of code. >I guess we try to statically play out all the current captures and >add the score to eval(). It is too "dangerous"(using the word from Ed), >like " ... why do static king safety when you have QS..." The situation >is too complicated with sliding pieces from the rear, etc and also checks. >Also it may return a score of +300, and it is a critical value. How >often do we have such positional aspect worth 300? > >So maybe someone can start discusion on "theoretical framework for chess >evaluation". I am now thinking it may be a good idea that eval() should only >include pure positional aspects only to make it clean. > >note: about Rebel including check moves in QS. the default is only the >next 2 ply from horizon and limited to max of 4. > >Rasjid
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.