Author: Uri Blass
Date: 02:54:53 06/01/05
Go up one level in this thread
On June 01, 2005 at 04:57:59, Gian-Carlo Pascutto wrote: >On June 01, 2005 at 01:47:12, Tony Werten wrote: > >>On May 31, 2005 at 20:31:38, Robert Hyatt wrote: >> >>>On May 31, 2005 at 15:32:25, Gian-Carlo Pascutto wrote: >>> >>>>On May 31, 2005 at 14:28:46, Robert Hyatt wrote: >>>> >>>>>On May 31, 2005 at 09:46:53, Gian-Carlo Pascutto wrote: >>>>> >>>>>>On May 31, 2005 at 01:21:54, Eugene Nalimov wrote: >>>>>> >>>>>>>>By this redefinition of EBF, I don't immediately see how any technique *can* >>>>>>>>have any effect on the EBF. >>>>>>> >>>>>>>Any technique that changes shape of the tree can easily cause change of the >EBF. >>>>>> >>>>>>Did you actually read the thread? He seems to be talking about some "other kind >>>>>>of EBF" where that does not happen. I can't explain it in any other way. >>>>>> >>>>>>>And now think about SE in particular. Without SE you can stop searching the node >>>>>>>the moment you have cutoff. With SE you should search further, thus increasing >>>>>>>EBF. [Of course you are searching extra subtrees, and those subtrees should >>>>>>>affect EBF, too, though I don't know what way]. >>>>>> >>>>>>Which is exactly what I and Robert have been saying... >>>>>> >>>>>>-- >>>>>>GCP >>>>> >>>>>I think that the confusion lies in that the EBF is usually computed as >>>>>time(ply)/time(ply-1). Where the real EBF could be considered the sum of the >>>>>moves searched at all nodes that are expanded, divided by the number of nodes >>>>>that were expanded (an average branching factor, more or less). >>>> >>>>No, because in both definitions an extension would behave as we normally expect, >>>>i.e. always increases BF. >>> >>>No. Think about it for a minute. It doesn't affect "the average moves per >>>node" whatsoever. It just drives the search deeper along certain paths... Even >>>if you do the DB/CB SE approach, the SE detection searches don't change the >>>"average branching factor" at all, as each node will still have about the same >>>number of moves to search... >>> >>>I think that is what is causing the confusion here. >> >>No, I think the confusion is that GC leaves the word "effective" out every now >>and then :) but I'm pretty sure he's only talking about ebf. >> > >Yes. But the distinction between both is pretty irrelevant for the point, which >was that Ricardo is using some defintion of branching factor which is totally >not the same as what is normally used (both effective and real), and then used >that to say "you are wrong". Another claim was that one can infer the 'goodness' >of an extension by it's effect on the branching factor (any kind). > >Both make no sense, and the first one will additionally lead to a lot of >confusion. > >That is now quite sufficiently proven, I think :-P > >Thinking of it, there are some extensions that will decrease the "true" >branching factor (as we normally understand it). Check extensions, for example. > >-- >GCP I do not see it. Check extensions only increase the branching factor(in other words the program need more time to get the same depth) Uri
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.