Author: Matthias Gemuh
Date: 10:05:59 11/23/01
Go up one level in this thread
On November 23, 2001 at 11:03:07, Gian-Carlo Pascutto wrote:
>On November 23, 2001 at 10:40:21, Robert Hyatt wrote:
>
>>On November 23, 2001 at 09:21:26, Matthias Gemuh wrote:
>>
>>>
>>>Hi Experts,
>>>look at this piece of code:
>>>
>>>
>>>p = 0; q = 0;
>>>
>>>int AlphaBeta(int depth, int alpha, int beta)
>>>{
>>> nLegalMoveCount = 0;
>>> if (depth == 0) return Evaluate();
>>> GenerateMoves();
>>> while (MovesLeft()) {
>>> MakeNextMove();
>>> if (!inCheck()) {
>>>
>>> nLegalMoveCount++; p = p + 1;
>>> if (nLegalMoveCount == 1) q = q + 1;
>>>
>>> val = -AlphaBeta(depth - 1, -beta, -alpha);
>>> UnmakeMove();
>>> if (val >= beta) return beta;
>>> if (val > alpha) alpha = val;
>>> }
>>> }
>>> return alpha;
>>>}
>>>
>>>
>>>Is the ratio q/p the thing bearing the sophiscated name "Branching Factor" ?
>>>Optimal move ordering should mean q/p = 1. Do Profis come close to this?
>>>In my pogram q/p is about 1/6 or 1/7. Must I weep ?
>>>
>>>Thanx,
>>>Matthias.
>>
>>
>>Nope. Branching factor would be total_moves_generated / total_movgen_calls
>>or some such estimate that tells you, on average, how many moves you generate
>>for a specific node.
>>
>>Effective branching factor (much more commonly used here) is the time to
>>search iteration N+1 divided by the time to search iteration N.
>
>From looking at his code, what I guess he's trying to do is to measure
>move ordering efficiency (but in a wrong way).
>
>The most common way to do that is fail-high-first rate. How many times
>when you fail high is it on the first move?
>
>>90% is usually considered good enough
>
>--
>GCP
Right! Move ordering efficiency is my problem. In the ratio you have described,
I hit a miserable 50...70 %.
Thanks.
Matthias.
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.