Author: Robert Hyatt
Date: 21:13:03 10/17/99
Go up one level in this thread
On October 17, 1999 at 16:45:43, Ratko V Tomic wrote: > Depth Tot.kN Delta.kN BF Time[s] Delta.T kN/s > ----------------------------------------------------- > 8 1044 .... .... 9.5 ... 110 > 9 2121 1123 4.70 18.5 9 115 > 10 5782 3661 4.53 47.75 29 121 > 11 15431 9649 4.31 124 76 124 > 12 62174 46743 4.36 495 371 125 > ----------------------------------------------------- > >> Argh. I'm still not getting this for some reason. I see how ply 12 >> is correct, but I don't see how the others are so high. Everything >> I've tried gives between 2 and 3 for them. > > >I added coliumn with time differences, which is what one would use in your >method of computing branching factor. That still doesn't give 4.3-4.7 range for >BF's. I guess it is much too inaccurate i.e. the additional time spent outside >of the evaluation function (and its variations/noise) is relatively too large >compared to the time inside evaluation for those shallower depths. The time >ratio method is a rough substitute when you don't have node counts. But if you >have node count N, then you can check that B^D gives you the right N (although >you need more significant digits for B than shown in the table to get the exact >numbers for Delta.kN, since B^D is very sensitive to small changes in B; this is >like compund interest calculation - a small change in interest rate makes a big >difference after 9-12 years of compounding), which is what BF definition (the >equivalent uniform tree) specifies. I don't think the 'difference' matters... whether you count nodes, or you use time per iteration, it really doesn't matter... but the time per iteration is _far_ better... because your node count method is dead wrong. it is assuming that "d" is a constant. It is not. D is very dynamic in crafty, particularly beyond the opening. Why not use the simple estimate of bf =Tn/Tn-1 which is easy to compute and is the basic cost for going from one ply to another, which is basically one half move deeper (although this is obviously a simplification due to the extensions and reductions in the depth being done...) We really don't care how many nods we search, only if we can go one more ply deeper or not, which is related to the clock more than the total nodes searched.
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.