Author: Robert Hyatt
Date: 16:41:06 07/27/04
Go up one level in this thread
On July 27, 2004 at 18:29:43, Gerd Isenberg wrote: >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. > I wrote about this many years ago in two JICCA papers, "Using time wisely" and "Using time wisely, revisited." It has worked well for me over the years... Yes it will screw up on occasion. Yes it pays off on occasion. You are playing the game of blackjack (21). You are dealt an Ace and a 3, the dealer has a 6 for his up card. What do you do? Only two real choices are hit or double down. The correct answer is double down. But, on occasion, "hit" would be better. But for the long-haul probability, double-down will return more money than simply hitting. That's the approach I use. What produces the best result overall? > >> >> >>> >>>> >>>>> >>>>>>> >>>>>>>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.