Author: TEERAPONG TOVIRAT
Date: 08:48:24 02/27/01
Go up one level in this thread
On February 26, 2001 at 12:49:21, Ralf Elvsén wrote:
>On February 26, 2001 at 12:05:12, TEERAPONG TOVIRAT wrote:
>
>>On February 25, 2001 at 05:44:43, Ralf Elvsén wrote:
>>
>>>On February 25, 2001 at 05:19:54, TEERAPONG TOVIRAT wrote:
>>>
>>>>
>>>>>and 16 make/unmake alternately. (sqrt(1*16) = 4). So maybe
>>>>>17/2 = 8.5 is better than 4? Why not measure these numbers instead
>>>>
>>>>The problem is we should use geometric mean ( y = sqrt (x))
>>>>or arithmetic mean (y= x/2) .
>>>>I'm not sure. Perhaps, some math experts here can help.
>>>>However, I prefer geometric mean...
>>>>Thanks for you opinion.
>>>>Teerapong
>>>
>>>It is definitely the geometric mean for the branching factor.
>>>So in average you have (1 + 16) moves per 2 nodes. Then of
>>>course you must take the arithmetic mean to get 8.5 :)
>>
>>I understand your point. But the basic idea of my test is try to imitate
>>the real life, in other word " in vivo" test.
>>If you loop 8.5 times,finally,you would get (8.5^ply) nodes instead of
>>approximately (4^ply) nodes.
>
>I must admit I don't understand what you mean above. But as I
>think you indicate below, count the numbers of make/unmake and
>movegens respectively in a real search to get the proportions.
>
>As much as I
>like the combination mathematics/computer chess, I don't
>like to apply imperfect theories (perfect moveordering alpha-beta
>without this and that...) to a real-world (in vivo) situation
>(your program I assume). I would take a good measurement instead
>anytime. This is what I suggested in a previous
>message. This doesn't solve the original problem of comparing
>different board representations since you can/will generate moves
>in different ways and probably have different quality on your move ordering,
>but to optimize a particular implementation I guess it will do.
>
>My current guess is that we agree on everything, but if I'm missing
>something interesting, please let me know.
>
>Ralf
I'm sorry for not giving more details in my last post. It was quite late at
night and there were a lot of things on my head .
In my last messege,I suggested we write a new pseudosearch().
And call it recursively to count number of visiting nodes then compare
with our real search().
int pseudosearch(depth)
{ nodes++;
if(depth==0) return
generate(); // 1 time
for( iteration X times) // we can change X here to see what happen to nodes
{ makemove();
x= pseudosearch(depth-1);
unmake();
}
return
}
And, from this function ,as you might guess if you let X=8.5 ,your total nodes
would be 8.5^depth (or ply). That is why I think it's a wrong number.
We can expect total searching nodes should be around 4^ply
(4=branching factor).
I may be wrong. I just try to learn every day especially computer chess.:)
Teerapong
This page took 0.01 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.