Author: rasjid chan
Date: 10:01:33 12/27/03
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.