Author: Vincent Diepeveen
Date: 06:10:37 07/23/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. At equal hardware at auto232 you get killed if not using them at 40 in 2 level. I don't doubt that at the icc server using last ply pruning and not using checks in qsearch work together very well. In diep i don't use last ply pruning yet (although i experimented with it of course a lot) and therefore i can do checks in qsearch. I think, and in that respec i agree with Bob, that you have to make choices. A lot of things are dependant upon each other. If you do a simple form of lastply pruning then i guess doing sophisticated things in qsearch is a lot harder. If you do fullwidth search, then using SE extensions seems a lot easier than when using nullmove. If your qsearch sees a lot, then it seems doing recapture extension makes a lot less sense. I guess there are a lot of choices, but for my DIEP, which is of course a slow program which always gets outsearched, and which always runs at slower or equal hardware when tested against other programs at the icc server and especially at auto232, then things might look different from having the fastest hardware with a program being very fast and pawnstructure code relying upon outsearching opponent. Greetings, Vincent
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.