Author: Cristian Zaslo
Date: 23:52:36 07/22/99
Go up one level in this thread
On July 22, 1999 at 18:00:39, Heiko Mikala 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. >> >>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 have been using check extensions in quiesce for about 10 years, under the >special condition, that the checking-series had to be started in the normal >search. I think this idea came from Bob Hyatt, as far as I remember they did >this in Cray Blitz too and called it Check Evasion Phase 3. I was very surprised >last year to find out, that Crafty works without check extensions in quiesce. >During the years, I have many many times tried to live without these extensions, >because they can make the search tree explode like hell, but I was never able to >live without them - I got simply killed in normal play without them. I guess the >reason for this is, that my program is very slow, and that I heavily relied on >extensions of all sort to extend the right lines, instead of beein highly >selective and pruning out all lines except the interesting ones. Just about a >week ago I tried again to remove check extensions in quiesce - and found out, >that now the versions with and without these extensions seem to be roughly equal >in strength. Maybe hardware is fast enough now, to even let my program search >deep enough to live without check extensions in quiesce. On the other hand, I'm >experimenting with a highly selective version right now with much reduced >extensions, so that my program searches even deeper because of that. > >But, as I said, for many years I was unable to live without check extensions in >quiesce, that's why I'm still searching for a good way to handle check's in >quiescence search. > >Heiko. I also experienced the node explosion of the searched nodes while using checks in the Q search. With this approach, my program seems to lose 1-2 plies in the full width search and determined me to give it out. By now, IMHO I think this problem could be partly fixed in two ways: 1. using a SCE, as you proposed. 2. trying *safely* checks *only* for 1-2 plies in the Q Search. Here again, a SEE is welcomed. This one maybe I’ll implement in the next version of my program. 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.