Author: Rémi Coulom
Date: 07:16:27 07/21/99
Go up one level in this thread
On July 20, 1999 at 21:02:38, David Eppstein wrote: >On July 20, 1999 at 16:43:47, Heiko Mikala wrote: >>These sentences convinced me. Now, do you have any ideas, how such a "SCE" >>could be implemented? Are there any existing papers about this, existing >>algorithms? > >I know of no existing papers etc, maybe someone else does. >But here are some half-baked ideas for categorizing checks: > >- Checks that set up an improved material balance. E.g. a fork, or a discovered >check where the discovering piece can capture next turn. A move where the >checking piece is on a safe square (i.e. attackers outweight defenders according >to SEE-type examination) but which causes some opposing piece to become unsafe. >If you can do a SEE quickly, it seems like you should be able to do this sort of >check evaluation as quickly, and this is primarily what I was thinking about as >the type of check you should look at in the qsearch. > >- Delaying tactics, checks that force a response but don't seem to make any >progress in winning material. I'm not sure if you want to search these or not, >probably not, but sometimes there might be a pot of gold (like checkmate) at the >end of a long forced sequence of moves. Maybe you should depend on the regular >search's check extensions to find these. > >- Stupid checks, that drop a piece (e.g. Bxf7+). Maybe they're not really >stupid but you definitely don't want to spend a lot of time looking for them in >the qsearch. Again, you should be able to figure out which ones these are using >the SEE. > >So, if you can distinguish (roughly) between tactical checks, delaying checks, >and sacrificial checks, it should be possible to do something useful with the >knowledge. Include the tactical ones in the qsearch, maybe. Or use different >amounts of check extension in the main search depending on what kind of check >you think it is. I think J.-C. Weill wrote in his PhD thesis that he did just this in one of his programs. The principle consisted in doing a depth reduction after the re-capture of a checking piece. This reduced the effect of the previous depth extension caused by the stupid checking move. IMHO, there is no need of this if you use null-move or other forms of forward pruning. If the check was really that stupid, the opponent will have easy null-move beta cutoffs in that branch of the tree, which compensates for the check extension. I think extensions should be triggered every time there is a forced move, even if it was caused by an apparently stupid sacrifice. > >Of course if you include checks in the qsearch, you also have to include moves >that get out of check, so that the side making the check can have a chance to >make the captures that the check was presumably setting up...so you definitely >have to have some mechanism for avoiding searching a long time down perpetual >check type lines. One quick and dirty way of doing this would be to not allow >one side to make two non-capturing checks in a row...this might be a useful way >to allow limited checks in the qsearch even without static check evaluation. I use checks in the q-search of TCB, but only in the first ply under some special conditions. The goal is mainly to prevent null moves from overlooking mate threats. This way I do not have problems with too much checks in the qsearch. Remi
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.