Author: José Carlos
Date: 16:33:03 12/27/04
Go up one level in this thread
On December 27, 2004 at 19:11:11, Uri Blass wrote: >On December 27, 2004 at 18:08:12, José Carlos wrote: > >>On December 27, 2004 at 17:05:26, Steve Maughan wrote: >> >>>José, >>> >>>>> Hi Steve, >>>>> Why "and (not_in_check)"? I mean, if you're going to reduce because you're >>>>> almost sure you're gonna fail low, being in check is not likely to >>>>> suddenly make you fail high... Am I missing something? >>> >>>As Uri said, if you're in check then it's not really a quiet position. IMO the >>>History Pruning heuristic can be useful for pruning the "Reh1" type moves. >>> >>>Steve >> >> Thanks Uri and Steve, now I see your point. But still, I'm not sure why it >>shouldn't work (note that I don't have history heuristic implemented, so I can't >>test nor speak from experience). >> Let's have a look at the pseudocode again: >> >> make_move; >> if (moves_made_already > 3) >> and (not_in_check) >> and (opponent_not_in_check) >> and (move_does_not_attack_opponents_king) >> and (history_value * 128 < best_history_value_from_this_node) >> then >> prune or reduce_depth; >> >> I guess (not_in_check) means _before_ making the move. If we make the move, >>now our king is not in check. We're trying to guess if the position after making >>the move is ok to reduce or prune, this is, it is a bad position for us. If I >>was in check, move out of check and still my position sucks, and it is my >>opponent's turn... I'm likely to fail low, right? >> I undertand that the main idea of this heuristic is to prune moves like Reh1, >>as Steve mentioned, but pruning a move where I get out of check in a lost >>position also makes sense. >> Could any of you try a quick test by removing that condition? >> >> José C. > >Maybe an example will help to explain it better > >I remember that I found that pruning move based on history when the king is in >check may cause problems here because white can play e7 and promote the pawn but >black has some checks before the promotion. > >You can say that the reason is a promotion threat and I can not prune when there >is a promotion threat but there may be other dangerous threats that the opponent >prevenet temproraly by checks and I do not detect all the dangerous threats. > >[D]8/p3q1kp/1p2Pnp1/3pQ3/2pP4/1nP3N1/1B4PP/6K1 w - - bm Ba3 > >Uri I see. So the point is after all that checks against me can hide a threat of mine. That makes sense. However, I'd rather catch my threats as much as possible. For example, don't prune if I have a pawn in seventh and the promotion square is empty (actually I have this condition for not pruning in Anubis, where I prune based on static conditions). But of course, checks against my king can hide my threats. It would be interesting to make an experiment (I'll try it when I have time): -Ignore the rule "don't prune if I'm in check" -If I'm in check and I decided to prune, search -If that search fails high, I have a hidden threat: save the position to a text file -Study and classify all the saved positions. Hopefully a few categories can be enough and those types of threats can be statically detected... José C.
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.