Author: Vincent Diepeveen
Date: 15:10:18 10/16/02
Go up one level in this thread
On October 16, 2002 at 08:12:00, Joachim Rang wrote: >On October 16, 2002 at 07:06:30, Vincent Diepeveen wrote: > >>On October 16, 2002 at 06:52:17, Gian-Carlo Pascutto wrote: >> >>>On October 16, 2002 at 06:39:08, Vincent Diepeveen wrote: >>> >>>>On October 16, 2002 at 06:37:40, Thorsten Czub wrote: >>>> >>>>>On October 16, 2002 at 06:33:39, Gian-Carlo Pascutto wrote: >>>>> >>>>>>It uses (I wouldn't say wastes) quite a bit of resources, >>>>>>but there is also a gain. I find that it is almost perfectly >>>>>>breaking even for me. I search less deep, but I am seeing >>>>>>some deep tactics and avoid getting into some dangerous >>>>>>situations. >>>>> >>>>>really ?! >>>>> >>>>>interesting. >>>>> >>>>>i gave up using SEX in rebel XP.... >>>> >>>>the problem of SE shows when search depths get big. >>>>GCP is basically testing at bullet levels and then you don't >>>>get search depths of 12+ ply soon. >>> >>>I don't notice them worsening things at longer time controls >>>either, but then again, I've never been a very deep searcher, >>>though things are changing. >>> >>>I also understand that you do the full Hsu thing, so your >>>overhead must be a lot bigger. >> >>I do way more. I can do way more. The nonsense lines get >>pruned by nullmove. In Hsu's creations they were not. >> >>>If I find that with increasing hardware speed/slower timecontrols >>>it does start getting worse, I will uncheck the 'singular extensions' >>>checkbox and problem solved :) >>> >>>>In DIEP the price of SE is basically getting too big at those depths. >>> >>>I gather from this you won't be using them this weekend? Or is >>>90m SD also 'bullet'? >> >>I am talking about the crucial 12 ply search depth for DIEP. >>I will be getting about 10-12, so the weakest spot is those 10 ply >>searches. There i will be using SE. >> >>My overhead at 10 ply is about half a ply for SE. But at 12 ply >>it can be easily 2 ply. Doesn't need to be so. Nullmove sometimes powerful >>prunes away the stuff in quiet positions. >> >>It's the tactical positions where sometimes even a 11 ply search depth >>has plies overhead. SE is a very stupid extension in fact. I am sure >>in the far future it's too stupid to let your b.f. worsen with it. >> >>It makes my b.f. simply a lot worse. With 3 ply reduction however >>the worsening starts not directly. Because in the root i don't do 'em >>and the last 3 ply i don't do them. So i save 4 ply. >> >>It's trivial that at 12 ply you feel it for 8 ply and at 10 ply you >>'just' feel it for 6 ply. >> >>In other words it's % from 10 ply is 60% of search depth. At 12 ply it's 75% >>of total search depth. >> >>That triggers more. >> >>Suppose in a few years we all get 15 ply. For me within 1 year perhaps >>(if i get some processors from NWO to use). I can't afford SE then simply. >> >>DB never was tested very well, let's be realistic here. Otherwise he >>might have kicked it out too and would have gotten more nodes a second >>then. >> > >So your testings showed, that SE create more overhead at deeper depth? What does >that cause? Why is the overhead at depth 10 about half a ply and at depth 12 >two? > >regards > >Jochim This is very easy to proof. Because you now and then extend a move, your overhead becomes bigger. So your branching factor becomes bigger, say from 'bx' to 'by'. So if you lose 0.5 ply now with that worse branching factor 'by', then 2 ply deeper from here you lose extra in plies: = (by^2 / bx^2) / bx = by^2 / bx^3 plies A major additional problem is that where bx is pretty constant, 'by' because of singular extensions is not constant. it's trivial that if at 10 plies of search DIEP has 6 plies where it could do a singular extension. This trigers at 60% of the search depth extensions. That's of course getting more when the search depth gets bigger. So there is more chance for those extensions to happen. So also observed with all such programs is that you do more and more of those extensions when depths get bigger. Also extensions overlap. In short sometimes 'by' gets radically worse. Each extra ply the program without SE needs just 'bx' to get deeper and a worsening 'by' which is already bigger than 'bx' of course loses to program using 'by' another ply. So when search depths in future get real big, then i can't use SE at all.
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.