Author: Uri Blass
Date: 01:23:50 01/22/04
Go up one level in this thread
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. I do not claim that finding best moves in normal fail high positions is a bad idea but it is not IID Uri
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.