Author: Robert Hyatt
Date: 16:59:08 05/30/05
Go up one level in this thread
On May 30, 2005 at 17:44:03, Ricardo Gibert wrote: >On May 30, 2005 at 16:06:38, Robert Hyatt wrote: > >>On May 30, 2005 at 07:23:24, Ricardo Gibert wrote: >> >>>On May 30, 2005 at 06:21:14, Pallav Nawani wrote: >>> >>>>On May 30, 2005 at 02:02:49, Amir wrote: >>>> >>>>>Deep Blue could calculate 200 million moves per second. According to what I have >>>>>read, Hydra calculates 40 million moves per second. How then is Hydra sees >>>>>deeper or is faster than Deep Blue, as is claimed by the authors?? >>>> >>>>According to the logs that I saw, deep blue was searching 12 plies deep in the >>>>K-DB match. My program can match that depth on a 1.1Ghz PC. This is because of >>>>search techniques that were not used in deep blue. Eg: Null move, Rebel style >>>>reductions, aggressive pruning. Hydra is obviously using such search techniques, >>>>and given its higher processing power, it will easily outsearch Deep Blue. In >>>>fact, in Shredder-Hydra match, shredder was searching to 16 ply (I think, but I >>>>could be wrong) which was almost the same as Hydra (Again, not sure). >>>> >>>>Also, Deep Blue was using Singular Extensions, which increases the number of >>>>nodes required in search. >>> >>>But which also reduces EBF. You should have left out this paragraph. >> >>No. In fact it increases it significantly. In Cray Blitz, it reduced our >>average search depth about 2 plies. Which is a significant _increase_ in >>effective branching factor. > >Most extentions result in a reporting of lower depth and an increase in nodes, >but this usually still means a reduction in ebf, because the depth reported does >not take into account the additional depth from the extentions. In short, the >depth reported underrepresents effective depth. As for SE I don't much about it, >but it must be a pretty crappy extention if it really increases EBF. > >> The extension itself may well help. But the cost of _detecting_ a singular move (or proving that a move is singular, whichever way you think about it) is quite high. In Cray Blitz, I did it like Hsu. It seemed to play better, but the cost was 2 plies in the middlegame. Dropping us from 11 to 9. In a few versions of Crafty, I tried it as Bruce Moreland had done in Ferret. I never had any luck identifying something that seemed to play better overall, but I occasionally go back and test again... However, if you want to make a search go fast, disable check extensions. It will likely get another ply of search if not more, but it will miss too many "horizon effect" moves and not play as well overall. >>> >>>> >>>>Also note that 9 plies of program 1 are not the same as 9 plies of program 2. >>>>These programs may be using different search techniques/extensions etc, and >>>>therefore on basis of plies searched you cannot guess the relative strength of >>>>programs. For instance, singular extensions are reputed to increase tactical >>>>strength quite a bit, but they may decrease the depth of search. >>>> >>>>Pallav >>> >>>I better though still imperfect comparison uses: >>> >>>effective_depth = log(nodes)/log(EBF) >>> >>>If given 2 programs where one reports a lower depth, because it does a lot of >>>extentions and another that reports a higher depth, because it does a lot of >>>pruning, but they otherwise generate the same search tree, then the above will >>>return the same effective_depth. >> >> >>log(EBF) is diluting the calculation. "nodes" is already included in EBF. > >ebf**depth = nodes >log(ebf**depth) = log(nodes) >depth*log(ebf) = log(nodes) >depth = log(nodes)/log(ebf) > >where ** denotes exponentiation > >It's an approximation for comparison purposes only. Right, but effective_depth = log(nodes)/log(EBF) what is "depth"? a big q-search makes that look like a big number. A minimal q-search makes it look like a shallower search. But it really isn't...
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.