Author: Gerd Isenberg
Date: 15:29:43 07/27/04
Go up one level in this thread
On July 27, 2004 at 16:08:32, Robert Hyatt wrote: >On July 27, 2004 at 15:25:46, Sune Fischer wrote: > >>On July 27, 2004 at 15:03:30, Robert Hyatt wrote: >> >>>On July 27, 2004 at 14:43:06, Sune Fischer wrote: >>> >>>>On July 27, 2004 at 13:33:40, Robert Hyatt wrote: >>>> >>>>>On July 27, 2004 at 09:42:46, Sune Fischer wrote: >>>>> >>>>>>On July 27, 2004 at 09:33:13, Anthony Cozzie wrote: >>>>>> >>>>>>>On July 27, 2004 at 03:18:50, Sune Fischer wrote: >>>>>>> >>>>>>>>On July 25, 2004 at 22:01:31, Robert Hyatt wrote: >>>>>>>> >>>>>>>>>Bad idea. Start the next iteration even if you don't think you will have time >>>>>>>>>to finish it. You might fail low. Wouldn't that be nice to know? :) >>>>>>>> >>>>>>>>This may or may not be a good idea. >>>>>>>> >>>>>>>>I think if it is a good idea, then you should always try and search the next >>>>>>>>iteration for a short time to see if you get a quick fail-low. >>>>>>>> >>>>>>>>On the other hand, if it is a bad idea it is better to save the time that will >>>>>>>>probably be wasted anyway. >>>>>>>> >>>>>>>>From what I can tell you propose to do a mixture, i.e. to use extra time if the >>>>>>>>time manager tells you to? >>>>>>>> >>>>>>>>I really doubt this is the best way, because it will be extremely random when >>>>>>>>you get to begin the next ply. >>>>>>>> >>>>>>>>-S. >>>>>>> >>>>>>>It seems you have 3 options here: >>>>>>> >>>>>>>Optimism: Hope that a move you haven't searched yet will fail high; terminate >>>>>>>after searching all moves. >>>>>>> >>>>>>>Pessimism: Make sure that the move you want to play won't fail low: terminate >>>>>>>after searching the first move. >>>>>>> >>>>>>>Don't Care: Just exit whenever time runs out ;) >>>>>> >>>>>>I think you have more choices, e.g. search the next ply, when time is about to >>>>>>run out, with a null window around the fail-low bound. >>>>> >>>>>I don't think any of that is reasonable. I have seen searches where the first >>>>>move takes 1 second to resolve a true score. I have seen searches where the >>>>>first move will talk almost forever to resolve the score. KISS is a good idea >>>>>here, IMHO. >>>> >>>>...which is why you shouldn't try and resolve the score. :) >>> >>>How is that KISS? IE I +normally+ try to resolve the score, so why change what >>>is the normal case??? For a special case that is not particulary significant. >> >>Because you could normally save 20% of your time?! >> >>Only way to know is to try it, I can only say it works for me :) > >How do you save _anything_?? By stopping early? I'd just as soon continue the >search, run out of time, make the move, and pick back up at the point of >interruption by hashing... > >I _never_ want to stop early. Every second I spend beyond "early" is a second >invested to detect tactical problems not yet noticed... Interesting approach, new to me! I also check time before starting a new iteration, estimating whether the new iteration exceeds the allocated time by some amount. If i think about it, yes the time starting the new iteration is not lost, even if the first root move is interrupted soon - one fills the hashtable. And the chance to probably find a decisive fail low and to allocate more time to avoid a loser is greater. > > >> >>> >>>> >>>>>> >>>>>>Just to assert as quickly as possible that it doesn't fail horribly low. >>>>>> >>>>>>Little sense in trying to resolve an exact score for the next ply if you only >>>>>>15% time left. >>>>> >>>>> >>>>>Often that is more than enough time to resolve the score. >>>> >>>>I think 15% is rarely enough time. >>> >>> >>>100 seconds per move. 15% is 15 seconds. For the first N iterations that is >>>more than enough time. How to accurately predict when you are starting the >>>_last_ iteration? >> >>Well, e.g. compare time remaining with the time spent on the last iteration, use >> a bit of logic and you might eventually get there... :) >> > >Again, been there, done that, got the T-shirt. Odd/even effects. I can show >you searches where iteration N+1 takes 1/2 the time of iteration N, because N >changed its mind too often. Feel free to use what you want, of course. I >simply use what experience says (to me) produces the best results. When I see >something I don't like, I fix it or live with it depending. > > > > > > >> >>>> >>>>If the whole last ply took 70% and the first move on the last ply took 60%, then >>>>you can probably expect to use about twice that, i.e. 120% time, to resolve the >>>>score on the first move. >>>> >>>>That's pretty hopeless unless something dramatic happens. >>>> >>>>-S. >>> >>>Try fine 70 for a quick counter-example... >> >>Howso? >> >>-S. > > > >Run it. Compare the times. it is one of many such positions where the first >move doesn't always take 90% of the total time. Particularly when the branching >factor drops as low as it does for fine 70. And then there is the odd/even >problem where sometimes odd or even iterations take _way_ longer than the >previous iteration, wrecking that percentage calculation you mentioned above...
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.