Author: scott farrell
Date: 22:44:29 01/09/04
Go up one level in this thread
On January 09, 2004 at 14:04:10, Tord Romstad wrote: >On January 09, 2004 at 12:51:47, Robert Hyatt wrote: > >>You are worrying about making the lug nut on one wheel perfect, when the rest >>of the truck is falling apart. SEE is _inherently_ inaccurate. It does not >>pay attention to pinned pieces, overloaded pieces, etc. It is used to choose >>moves and move order searched by the q-search, which is _also_ full of holes, >>it doesn't look at moves that pin pieces, unpin pieces, xray/skewer pieces >>and so forth. > >This is all true, but you can still do better than just giving up. > >In theory it is of course possible to write a very complicated SEE which >evaluates the positions Uri presented correctly. But such an SEE would >probably be so slow that it is not worth the effort. > >What you can do, however, is to estimate the complexity of the position >(I do this as part of my evaluation function) before generating captures >and using your SEE. Then your engine can make decisions like "oh, >there's a lot of hanging, pinned and overloaded pieces here, I shouldn't >trust the SEE at this node", "this is easy, my opponent has this big >juicy hanging piece just waiting to be eaten, none of my pieces are >pinned or hanging, let's just return a fail high search at once" or >"looks like there could be a back rank mate here, let's search checks >as well as captures". > >By using such techniques, it is possible to have a qsearch which is >*more* accurate than a minimalistic qsearch with a simple SEE, while >searching *fewer* nodes in most positions. At some qnodes you search >all captures, at some nodes you only search winning and equal captures, >and at some nodes the SEE gives a sufficiently accurate estimate that >you can just return a score without searching any moves at all. > >Tord I like this idea, and other's ideas where it is suggested you flag a position as 'complicated' or 'dont-prune-move-in-qsearch', instead of returning a flaky answer, return 'I dont know'. I am also expermenting with: - incremental attacks board vs attack boards (not incremental) - no attack boards - SEE on even/loosing capture, no SEE where the capture is obviously good (enpris or capture wins directly ) - what to do with even captures? Some things I have learned : no attack boards works great if you reduce the reliance on SEE, as SEE needs the attackTo boards. even capture mostly return just that from SEE, even. That if you have no attack boards, it is less compute time to just search the even capture as the attackFrom in make move etc is faster than the multiple attackTo required by SEE. And you probably get better positional play as you get to value the position after the captures. SEE and attackBoards are nice at inner (no leaf) nodes and for other things like extension control etc. if you are going to use attackBoards, clearly SEE should be used on even and losing captures. As the attackBoards make it really fast. other topics of interest: I made a SuperSEE, that does pins/checks/discovered attacks and uses alpha/beta and non fixed move ordering. It is way more accurate, not noticeably slower, but doesnt help at the leafs becuase there isnt enough to be gained. I am thinking of using it at interior nodes more. Its amazing at its ability to solve complex positions without any nodes at all !!!! relies heavily on the existance of attackTo boards obviously. Scott
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.