Author: Dave Gomboc
Date: 19:06:42 03/28/00
Go up one level in this thread
On March 28, 2000 at 17:19:34, Andrew Dados wrote: >On March 28, 2000 at 16:41:17, Dave Gomboc wrote: > >>On March 28, 2000 at 13:27:59, Andrew Dados wrote: >> >>>On March 28, 2000 at 13:14:59, Dave Gomboc wrote: >>> >>>>On March 28, 2000 at 12:17:14, Tom Kerrigan wrote: >>>> >>>>>On March 28, 2000 at 11:08:59, Bas Hamstra wrote: >>>>> >>>>>>Question is: is move ordering very important near the root and less important >>>>>>near the leafs? Bob Hyatt says so. One mistake near the root costs millions of >>>>>>nodes. On the other hand almost all nodes are leafnodes, so bad ordering near >>>>>>the leafs costs millions of nodes too. >>>>> >>>>>I think so. At least in my program, hash table size does not matter much. (See >>>>>previous posts in this thread.) >>>>> >>>>>>Has anyone measured if you search somewhat deeper if you do extensive ordering >>>>>>near the root and cheap (just MVV/LVA) ordering near the leafs and in the >>>>>>qsearch? >>>>> >>>>>Because SEE only improves things by ~%10 over MVV/LVA, I don't think doing SEE >>>>>at the root and MVV/LVA otherwise would make much sense. You can do searches to >>>>>improve move ordering, which is the idea behind internal interative deepening. >>>>>So yes, people are doing this, and I believe it works, although I haven't tried >>>>>it myself. >>>>> >>>>>-Tom >>>> >>>>I have yet to figure out why people who use iterative deepening and understand >>>>why it works do not also use internal iterative deepening. Could somebody >>>>enlighten me? >>>> >>>>Dave >>> >>>It will only work when node you do it at will fail high, otherwise it's waste of >>>nodes... so eg Bob does it along PV and only when no good move from HT... Some >>>programs have 'double null move', which accomplishes pretty much the same. >>> >>>-Andrew- >> >>(I wasn't suggesting to use it everywhere.) >> >>I don't understand how double null-move accomplishes pretty much the same (no >>doubt because I'm not exactly sure what you mean by "double null move" ;-). >>Let's say you have depth 7 left to go, and you see that don't have a good move >>from the hash table. IID will pick a move using searches of depths 1-7... and >>the searches at low depths are no more wasted than they are with normal >>iterative deepening. What will "double null move" do in this circumstance? >> >>Dave > >IID idea is to get a good move to try first. If there is a move from HT which >failed high on previous iteration, then IID is useless here (will get same info >as stored in HT). Same for fail low on previous iteration (IID will get fail low >here as well with no good move). Like I said, I didn't suggest using IID everywhere! I take that for granted, but I should have been more explicit, I guess. More concretely: let's take the situation where the hash table lookup comes up with no information. That's a basic situation where I think IID can be useful. Let's also assume that there is a reasonable amount of depth left to go. (People can always come up with tricks if there's hardly any depth left -- which isn't relevant to the main debate.) >If there is no data in HT (entry was owerwritten) we don't know whether this >node will get FL (IID will just waste nodes here) or FH (IID can be useful to >get a good move, but maybe our move ordering is good enough not to try IID). So in the case where there is going to be a fail-low, you think that doing IID will use more time than just searching every move immediately at the required depth? Why? (If that's not what you meant, then I misunderstood you.) I specifically disbelieve this, for the same reason that I disbelieve that iteratively deepening from ply 1 to ply 7 "will just waste nodes" compared to starting out with a ply 7 search. >Either way - IID in *most* cases will not save us a bit, but add useless nodes. >If we could be sure that given node will fail high (or we search non-zero >window) IID would probably save us nodes by giving a good move to search first. >(Note Bob estimates some 10% less nodes in many positions when doing IID along >PV, when we can be fairly sure score will fail within window) > >Double null trick is to allow 2 null moves in a row (but not 3). Idea is to >detect zugzwang positions while using advantage of null move pruning. >Practically it's then IID with reduced depth of (2*null_reduction). It's not practically IID at all, if IID isn't implemented. Dave
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.