Author: Dave Gomboc
Date: 12:54:15 03/30/00
Go up one level in this thread
On March 30, 2000 at 01:37:33, Andrew Dados wrote: >On March 29, 2000 at 23:50:51, Dave Gomboc wrote: > >>On March 28, 2000 at 23:30:11, Andrew Dados wrote: >> >>>On March 28, 2000 at 22:06:42, Dave Gomboc wrote: >>> >>>>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.) >>> >>>That's what I ment, yes. You *have to* search all the moves at that ply to full >>>depth anyway, so searching first to depth 1, then 2, etc is not helpful at all >>>in FL node. You'll waste all those nodes. >> >>"not helpful at all"? IID will give you better move ordering than you could get >>statically, which should save you work overall. >> > >Just curious... what 'better move ordering' in FL node? Any move ordering is as >good as other there (we will search all moves and all will fail low)... and that >was my main point. To show that it is a fail-low node, you have to refute each move. Better move ordering allows you to do this more quickly. I think your main point is actually incorrect. 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.