Author: Robert Hyatt
Date: 20:34:22 08/15/01
Go up one level in this thread
On August 15, 2001 at 17:20:26, Peter McKenzie wrote: >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. >> >> >>> >>>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. > >Whether it does or doesn't work isn't the point I was trying to make. The point >I was trying to make is that it could *conceivably work*. > >That is, if FHBest just happens to be sufficiently high, then keeping track of >the 'best' move at fail low nodes would be a useful piece of information for >move ordering if the position is seen again. That is certainly possible. I know how often I fail high on the first move compared to failing high on something other than the first move. But I have no idea how often the move I fail high on is really the best one. I suspect it is not nearly so often as I would like, but fortunately alpha/beta doesn't really care. IE in the case of a killer, the killer might be a fork of rook and queen, which wins an exchange. But there might be a better fork in this particular position, namely queen and king, which wins more. But the exchange is enough to cause the fail high and away we go with the way wrong backed up bound... > >> >> >> >> >>> >>>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.