Author: Robert Hyatt
Date: 06:38:56 01/22/04
Go up one level in this thread
On January 22, 2004 at 04:23:50, Uri Blass wrote: >On January 21, 2004 at 20:53:00, Robert Hyatt wrote: > >>On January 21, 2004 at 18:21:28, Tord Romstad wrote: >> >>>On January 21, 2004 at 14:14:00, Robert Hyatt wrote: >>> >>>>On January 21, 2004 at 13:34:27, Tord Romstad wrote: >>>> >>>>>Yes. This is why it is a good idea not to do IID at all nodes, but only >>>>>at nodes where you are reasonably sure that there will be a fail high. >>>>>You should always check the value of the static eval before doing the >>>>>internal search. >>>> >>>>I don't even think you want to do it at fail-high nodes. Just at nodes >>>>where you expect a "true score". At least that is how _I_ have implemented >>>>it. >>> >>>I use MTD(f), hence I *never* get any "true scores" anywhere in the tree. >> >>Why? I played with mtd(f) for several months right after Don Daily started >>his "you got to try this" many years ago... I got exact scores, because the >>last two searches have a common "edge" and that "edge" is the true score. >> >> >>> My >>>intuition >>>regarding PVS is not very good (I have used MTD(f) almost since the beginning), >>>but >>>I don't see any reason not to use IID at all expected fail-high nodes in a PVS >>>search, >>>too. At a fail-high node, you can return a value before all moves are searched. >>> If >>>your move ordering is perfect, you will only need to search one move. It >>>therefore >>>makes sense to make some extra effort to make sure that the first move searched >>>will really return a score >= beta, and the most obvious way to do this is to >>>first >>>do a search with reduced depth. What am I missing? >>> >> >>for the majority of moves, it is easier to find a capture refutation than to >>do an N-iteration search... I tried it both ways (plus other ideas) when I >>first did this. What I am doing right now has really proven to be effective >>with no particular down-side or risk... >> >>For normal fail-high positions we have already been doing iterated searches >>for previous depths, so hopefully we get decent ordering here most of the >>time using normal ideas. The critical positions are the PV nodes, because >>there searching a good move first is not good enough. We need the _best_ move >>first. At normal fail-high positions, we only need a move good enough to cause >>a cutoff, not the best move. IID will provide the best move generally, but at >>significant cost. > >I do not see how IID gives the best move at normal fail high position. >It can give one move with score better than beta and not the best move. Easy. It doesn't. Because I don't use IID at a "fail high" position. I only use IID on PV nodes. Most of the time _those_ don't fail high. In fact, the reason I am in this situation is most likely the root move failed high, and now I am re-searching with a much bigger upper bound, and can't fail high here. > >I do not claim that finding best moves in normal fail high positions is a bad >idea but it is not IID > >Uri Nope. But then I don't do IID at "normal fail high positions" as I see no benefit there, only along the PV where the tree is _much_ larger than at other fail-high/fail-low positions.
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.