Author: Robert Hyatt
Date: 08:43:41 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'm not even sure the check extension will do that, except when it occurs at the last full-width ply. For example, at shallow interior nodes. we are going to search the position following the check normally, and its branching factor will be lower since it is a "check escape" position. But below that there is no guarantee that there will be any further checks, so we may just have a normal tree with a normal branching factor, which will actually tend to pull the branching factor up because there will now be even more "normal branching factor nodes" to search with the extension in place. If it happens at the last ply, then it is possible that the extension causes us to search the next ply full-width to get out of check, with a reduced branching factor since it is an escape-check position, but then we have a limited q-search node to follow that, which would appear to slightly lower the average branching factor somewhat... The net effect might be near zero.
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.