Author: Gian-Carlo Pascutto
Date: 04:16:30 06/01/05
Go up one level in this thread
On June 01, 2005 at 05:54:53, Uri Blass wrote: >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, most of this thread revolves about discussion about what the "branching factor" is. I suggest you try to deduce the *meaning intended* first before replying, instead of jumping in and missing the bat completely. Look at Robert's post for a hint. -- GCP
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.