Author: Cristian Zaslo
Date: 02:52:24 07/22/99
Go up one level in this thread
On July 21, 1999 at 10:16:27, Rémi Coulom wrote: >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 I agree with you. I do checks on the first ply in the Q search part to avoid both null move and razoring errors. It seems to me that it works fine. Regards, Cristian
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.