Author: Robert Hyatt
Date: 19:55:42 06/23/00
Go up one level in this thread
On June 23, 2000 at 21:07:26, Peter McKenzie wrote: >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! > There I agree... >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. There is an alternative. Moving the "good stuff" into the basic search where all moves are considered, rather than trying to do it in the q-search where errors only compound errors. I have no idea if my idea is right or wrong. I've done both kinds of q-search approaches. But I definitely like the current simple one.
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.