Author: Robert Hyatt
Date: 07:28:26 08/16/01
Go up one level in this thread
On August 16, 2001 at 08:10:18, Vincent Diepeveen 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. > >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). > If this is true then you have something else going on. I (and others) ran this test a couple of years ago and it hurt each of us. I try the hash table move before anything else. If it is not good enough to cause a cutoff, this hurts the search, assuming some other move _will_ cause a cutoff. I have to do a move generation that I avoid if the hash table move fails high, for example. >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. I would try to find out why it helps and why your normal move ordering doesn't pick up a good move there as well in many cases. Perhaps you are not doing the "don't call move generator until after searching hash table move" trick?
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.