Author: Peter McKenzie
Date: 18:07:26 06/23/00
Go up one level in this thread
On June 23, 2000 at 16:16:14, Robert Hyatt wrote: >On June 23, 2000 at 14:27:32, Andrew Dados wrote: > >>On June 23, 2000 at 02:06:27, Bruce Moreland wrote: >> >>>On June 22, 2000 at 17:38:37, Vincent Diepeveen wrote: >>> >>>>On June 22, 2000 at 08:29:03, Robert Hyatt wrote: >>>> >>>>>On June 22, 2000 at 07:55:53, Vincent Diepeveen wrote: >>>>> >>>>>>On June 21, 2000 at 11:12:23, Robert Hyatt wrote: >>>>>> >>>>>>>On June 21, 2000 at 11:03:42, David Rasmussen wrote: >>>>>>> >>>>>>>>I find that a lot of the games that my program loses, it loses because it >>>>>>>>doesn't search checking moves in qsearch. >>>>>>>>Anyway, how do people do that most effectively? I would like not to generate all >>>>>>>>moves in the qsearch (just the captures), but then I will miss the noncapturing >>>>>>>>checks. >>>>>>> >>>>>>> >>>>>>>I did them in Cray Blitz, and in early versions of Crafty. But I haven't >>>>>>>done checks in the q-search since just prior to the Jakarta WMCCC event. >>>>>>> >>>>>>>You can control them to an extent... ie when you get to the q-search, you >>>>>>>can consider a check. But if you look at a capture at the first ply or 2, >>>>>>>then there is little point in doing checks deeper in the q-search because the >>>>>>>'stand pat' will allow you to avoid the checks totally, earlier in the >>>>>>>tree. >>>>>> >>>>>>76% of all checks give a cutoff in DIEP in qsearch >>>>>>on average a check improves score with 2.9 pawns >>>>> >>>>>That is fine. But if 76% of checks are giving cutoffs, you have a problem >>>>>somewhere else, because _most_ cutoffs should be produced by captures, not by >>>>>checks. >>>> >>>>That's pretty hard to measure in a realtime program and i disagree here. >>>>If you're in check, then you don't need to evaluate and have limited choice, >>>>so the number of nodes you cycles you waste when being in check is >>>>quite limited. >>>> >>>>3 out of 4 checks giving a cutoff in a position which wasn't a cut node >>>>without trying the check (otherwise beta pruning) is pretty good i think. >>>> >>>>I'm sure most don't get such a good cut rate. >>> >>>I don't see how this makes any sense. Why would a check give a cutoff unless >>>it's a mate, a capture, or the subject of an eval function bonus? >>> >>>bruce >> >>[D]4k3/8/8/8/r7/8/6Q1/4K3 w - - >> >>We're in qsearch here. Qxc6+ Kxx QxR will give a cutoff, no? >>-Andrew- > > >So will an eval term that says KQ vs KR is an easy win if the queen isn't >lost. But for every such tactic you find in the q-search, there are even >more you miss by not considering anything but checks and captures. Why make >the q-search _bigger_ if it is already horribly inaccurate? The q-search may be horribly inaccurate, but its still much more accurate than the static eval function - otherwise we wouldn't bother with q-search at all! If we can make q-search more accurate then surely this is a good thing, all else being equal. Of course all else isn't equal, as checks cost us CPU time and extra nodes. It then becomes a simple question of cost benefit: do the undeniable benefits outweigh the costs? Like most tradeoffs, this is tough to answer and could well vary between implementations. I think there a very strong programs with and without checks in q-search, so its probably not that important.
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.