Author: Vincent Diepeveen
Date: 05:10:18 08/16/01
Go up one level in this thread
On August 15, 2001 at 09:39:05, Robert Hyatt wrote: >On August 15, 2001 at 01:20:41, Peter McKenzie wrote: > >>On August 15, 2001 at 00:06:00, Robert Hyatt wrote: >> >>>On August 14, 2001 at 21:51:49, Dieter Buerssner wrote: >>> >>>>On August 14, 2001 at 00:37:15, Robert Hyatt wrote: >>>> >>>>>On August 13, 2001 at 14:07:43, Dieter Buerssner wrote: >>>>> >>>>>>On August 13, 2001 at 00:01:35, Robert Hyatt wrote: >>>>>> >>>>>>>On August 12, 2001 at 23:49:35, Pham Minh Tri wrote: >>>>>>> >>>>>>>>How about the UPPER? Should we choose the move has score nearest alpha (the >>>>>>>>highest score or the first of highest ones)? Perhaps store something is better >>>>>>>>than nothing. >>>>>>>> >>>>>>> >>>>>>>Nope. Something is not better than nothing here. In a LOWER position, every >>>>>>>move was refuted by the next ply. >>>> >>>>Much snipped, but I will come back to this later. >>>> >>>>>Note that I use fail-soft as well. >>>> >>>>Then, I must totally misread your source. You don't keep track of the best >>>>score, when it is lower alpha. You allways return alpha, in the case of an upper >>>>bound node. This will move earlier be beta. So, this looks essentially as fail >>>>hard to me. >>>> >>> >>> >>>If a call to search returns a value < alpha, I return that value to the >>>previous ply, not the original alpha. But if you search each move at a ply, >>>and you get a score <= alpha for each, you can _not_ reasonably expect those >>>scores to reflect anything about which move is better. It just doesn't >>>work like that. At the next ply you fail high as soon as you find a score >>>>= beta. Not necessarily on the _best_ move, just on _any_ move that will >>>produce a score >= beta. And since you don't search all moves to find the >>>largest fail-high, how can you use tht result at the previous ply to find >>>the worst move? Answer is, you can't, reliably. >> >>Hi Bob. I think we all understand what you are saying in this paragraph. But >>lets for a moment assume that when you fail high, your move ordering is so good >>that you fail high with the best move *most* of the time. We will call this >>ratio the FHBest ratio, being the number of times you fail high with the best >>fail high move divided by the total number of fail highs. > > >Sure... but that is really a useless piece of information. For alpha/beta to >work optimally, you don't necessarily have to search the _best_ move first, >except along the PV. The rest of the time all you want is a move good enough >to cause a cutoff, regardless of whether there are better moves or not. This >is why killers and history work so well. From theoretic viewpoint you are completely correct Bob, but practical seen the only information we have about a position P here is the best move stored in transpositiontable. Though loads of time this isn't the best move from alfa/beta viewpoint, it improves on average my move ordering at <= alfa nodes with around 1.0% to use a move from hashtable (of course <= alfa as stored in hashtable as we do not know yet whether we go fail high or fail low now before search has been done). I have tried to find rules when a such a move stored in transpositiontable should get applied and when not, but so far the only thing working for me is always using it. Improvement of 1% from a move ordering is quite something in fact when talking to the extra depth you get. Best regards, Vincent > >> >>Now of course, we can't measure FHBest unless we do a true fullwidth search, but >>lets just assume that it is high. >> >>If FHBest is sufficiently high (don't ask me how high is sufficient :-), more >>often than not we could determine the best fail low move. We aren't *certain* >>that it is the best fail low move but, if FHBest is high enough, we know that it >>*probably* is the best fail low move. >> >>So it would make sense to give the probable best fail low move a bump up the >>move list when re-searching this position at a later time. > > >Try it. Ed used to do this in Rebel. He reported a 10% _improvement_ by >removing it after listening to this exact same discussion a few years ago. >Trust me, it doesn't work. > > > > >> >>Peter
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.