Author: Robert Hyatt
Date: 13:08:32 07/27/04
Go up one level in this thread
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... > >> >>> >>>>> >>>>>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.02 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.