Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: move ordering and node count

Author: Dann Corbit

Date: 14:27:35 03/29/04

Go up one level in this thread


On March 29, 2004 at 17:12:51, Uri Blass wrote:

>On March 29, 2004 at 16:58:58, Dann Corbit wrote:
>
>>On March 29, 2004 at 16:35:29, Dann Corbit wrote:
>>
>>>On March 29, 2004 at 16:22:21, martin fierz wrote:
>>>
>>>>On March 29, 2004 at 15:50:10, Dann Corbit wrote:
>>>>
>>>>>On March 29, 2004 at 10:17:18, martin fierz wrote:
>>>>>
>>>>>>aloha!
>>>>>>
>>>>>>i was discussing this somewhere in a thread, but thought i'd like to make this
>>>>>>question more visible in the hope of getting a good answer:
>>>>>>
>>>>>>everybody knows that with plain alpha-beta, a fixed number of moves N per node,
>>>>>>and perfect move ordering a search to depth D needs
>>>>>>
>>>>>>nodes(depth) = sqrt(N)^(D/2) nodes.
>>>>>>
>>>>>>with absolutely imperfect move ordering it needs
>>>>>>
>>>>>>nodes(depth) = N^(D) nodes.
>>>>>>
>>>>>>a typical chess program gets something like 90% move ordering in the sense that
>>>>>>if a cutoff move exists, it will search it as first move in 90% of all cases.
>>>>>>here's my question:
>>>>>>
>>>>>>can anybody give an estimate for nodes(depth) as function of this move ordering
>>>>>>parameter? obviously, this would also depend on when you find the best move in
>>>>>>those cases where you don't find it first. any kind of model is acceptable, e.g.
>>>>>>you always find it on 2nd, always on sqrt(N)th, always last, at a random number,
>>>>>>whatever. i'm just interested in the general behavior of nodes(depth) as a
>>>>>>function of the cutoff-%age.
>>>>>>
>>>>>>i'd be extremely surprised if nobody ever estimated this, so: has any of you
>>>>>>ever seen or calculated such numbers, and if yes, what do they look like?
>>>>>>
>>>>>>and is there any theory how this would apply to a modern chess program with
>>>>>>nullmove and extensions instead of the plain A/B framework above?
>>>>>>
>>>>>>basically this question of course means: do you really gain anything tangible
>>>>>>when improving your MO from say 90% to 92%?
>>>>>
>>>>>I have not done the math, but I am guessing no matter what king of move ordering
>>>>>you have (purely randome or the pv move every time) you will get something like
>>>>>this:
>>>>>
>>>>>nodes = some_constant * sqrt(mini_max_nodes)
>>>>>
>>>>>If you have random move ordering, then the constant will be very large.
>>>>>If you have perfect move ordering, then the constant will be very small.
>>>>>
>>>>>You will never get worst case unless you try very hard to achieve it.
>>>>>It might be possible to degenerate to mini-max (or very close to it) but you
>>>>>will have to choose the worst possible move at every single turn except the
>>>>>leaves.  I doubt if anyone can do it.
>>>>>;-)
>>>>
>>>>i disagree with your formula. it is definitely not some_constant. it is a
>>>>constant between 1...sqrt(N) taken to the power of D/2. else there would be no
>>>>point in improving move ordering, or at least, not as much as there is :-)
>>>
>>>What if the constant is one trillion?
>>>
>>>If you choose the node at random, you will still find the right one by random
>>>chance on the first try 1/n times (where n is the number of moves) and on the
>>>second try 1/(n-1) times, etc..  On average, we won't have to try more than half
>>>of the nodes to find it (the best one).   This will cause a huge reduction in
>>>the number of nodes.
>>>
>>>As you can see, you would have to put forth a stupendous effort to cause minimax
>>>behavior.
>>
>>Consider also that the 2nd best nodes will prevent lots of searches (all except
>>the best node), as well as the 3rd best (all except the top 2 nodes), etc.  So
>>alpha-beta even with very bad move ordering will still cause a huge number of
>>cutoffs.
>
>I do not see what your words has to do with martin's post.
>
>The claim is only that the following formula is wrong:
>nodes = some_constant * sqrt(mini_max_nodes)
>
>It is not saying that nodes is the same as mini_nmax_nodes.
>
>You can have mini_max_nodes^0.51 that means that the difference is getting
>bigger when the depth get bigger when the wrong formula of you suggest
>difference that is not dependent on the depth.

WHat I am saying is that the depth reduction will be directly proportional to
the square root of the minimax nodes.  It does not matter if you pick the best
node or not.  If you pick badly all the time, there will be a large constant of
proportionality introduced.  If you pick the best node all of the time, then the
constant will be close to 1.



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.