Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Null move question

Author: Omid David Tabibi

Date: 08:33:28 08/02/03

Go up one level in this thread


On August 02, 2003 at 11:07:35, Tony Werten wrote:

>On August 02, 2003 at 06:33:54, Omid David Tabibi wrote:
>
>>On August 02, 2003 at 06:00:57, Tony Werten wrote:
>>
>>>On August 02, 2003 at 04:02:29, Omid David Tabibi wrote:
>>>
>>>>On August 02, 2003 at 03:44:06, Tony Werten wrote:
>>>>
>>>>>On August 01, 2003 at 22:45:11, Robert Hyatt wrote:
>>>>>
>>>>>>On August 01, 2003 at 05:09:59, Tony Werten wrote:
>>>>>>
>>>>>>>On July 31, 2003 at 18:15:47, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>On July 31, 2003 at 14:23:34, Tony Werten wrote:
>>>>>>>>
>>>>>>>>>On July 30, 2003 at 17:18:12, Rick Bischoff wrote:
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>a. at depth 3- hash table is empty for this position.  alpha = -INF, beta = +INF
>>>>>>>>>>>>a. all requirements for null move are met
>>>>>>>>>>>>a. makes null move:  int e = -alphabeta(depth - 3, -beta, -beta +1);
>>>>>>>>>>>>
>>>>>>>>>>>>b. now we are at depth 0, alpha = -INF, beta = -INF + 1
>>>>>>>>>>>>b. we call quies(alpha, beta)
>>>>>>>>>>>>
>>>>>>>>>>>>c.  e = static eval is, oh say, 1.
>>>>>>>>>>>>c.  e >= beta, return beta
>>>>>>>>>>>>
>>>>>>>>>>>>b. store this position in the hash table as -INF + 1, exact, depth = 0, return
>>>>>>>>>>>>-INF + 1
>>>>>>>>>>>
>>>>>>>>>>>This is _way_ wrong.  How can it be "exact"???  It is impossible for the
>>>>>>>>>>>search to return valid scores outside alpha/beta window as defined at the
>>>>>>>>>>>root.  If you are returning an "edge" then it must be an upper or lower
>>>>>>>>>>>edge, not an exact score.
>>>>>>>>>>
>>>>>>>>>>Yes, I know it is wrong-- which is why I was asking the question to begin with
>>>>>>>>>>:-) What I do know is store anything quies returns as exact-- but you are
>>>>>>>>>>telling me I can't do that, right?  (Forgive my ignorance!)
>>>>>>>>>
>>>>>>>>>You are correct (despite what the others say), but only if you use the failsoft
>>>>>>>>>version of alphabeta.
>>>>>>>>>
>>>>>>>>>Tony
>>>>>>>>
>>>>>>>>I don't see how he can be correct even with failsoft.  If you get a score
>>>>>>>>outside alpha/beta it is _never_ an exact score, it will only be a bound.
>>>>>>>
>>>>>>>No it isn't. If you evaluate and take a beta cutoff, the evaluationscore is
>>>>>>>still exact, has nothing to do with bounds.
>>>>>>
>>>>>>Never heard of "lazy evaluation?"
>>>>>
>>>>>AFAIK lazy eval isn't part of alphabeta.
>>>>>
>>>>
>>>>In alphabeta when you return a value >= beta, it means that the score is at
>>>>least value, but can also be greater than value. So, by no means can this be
>>>>considered an exact score. If you are certain that this fail-high returned score
>>>>is the direct result of a full static evaluation, this is another story; in this
>>>>case you can store it as exact score at depth 0. But the father node can never
>>>>be sure that the value returned from the son is the score of static eval.
>>>>
>>>>For example, in quiescence I use:
>>>>
>>>>value = eval();
>>>>if (value >= beta)
>>>>    return value; // not an exact score, as the real score can be greater
>>>
>>>No it can't. You just did an eval. If you don't consider this exact, then you
>>>never have an exact score,( or upper or lower ). Searching a few ply more can
>>>always change the score.
>>
>>Exact score isn't defined as static eval in the node. If it was so, you could
>>have done a static eval in the root node and get the exact score for it.
>>
>>The definition of exact score is the best score returned from all the possible
>>moves from the current node (and alpha < value < beta). If you don't search all
>>the moves, you simply can't have an exact score. The only exception is of course
>>a leaf node, in which by definition we apply static evaluation since no moves
>>are going to be searched. But if there are moves going to be searched (e.g., in
>>the quiescence example above), exact score cannot be determined unless you
>>search all the moves (captures for this matter).
>
>This is wrong. It was believed that there can only be returned an exact
>movescore when it was between alpha and beta (wich was wrong). Now you turn it
>around and say it can't be exact when it's not between alpha and beta.
>
>I have a static mate detection, wich returns checkmatescores. Pretty exact don't
>you agree ?

Yes, since it is independent of the bounds, just like the draw scores.


>
>If eval returns >=beta this node is a leafnode and therefore exact.
>
>If you search a few captures and didn't improve evalscore then you agree it's
>exact ? Yes, but only because you choose to ignore the moves that possibly lower
>the score.

Sure, by "score" we mean "best score".


>
>Only if bestscore is improved by search then it's not exact but a lower bound.
>
>Tony
>
>>
>>I store every node in the hash table as following:
>>
>>if (best >= beta)  // value >= beta
>>    store_hash(hkey, best, FLAG_B, depth, bmove);
>>else if (improve)  // orig_alpha < value < beta, i.e., alpha was improved
>>    store_hash(hkey, best, FLAG_X, depth, bmove);
>>else               // value <= alpha
>>    store_hash(hkey, best, FLAG_A, depth, bmove);
>>
>>
>>>
>>>Tony
>>>
>>>>
>>>>
>>>>
>>>>>Tony
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>If you evaluate below beta then there are 2 possibilities. In the end, best
>>>>>>>score didn't improve, score is still eval, and eval is exact.
>>>>>>>Second, bestscore did improve, must have been by search, so read from start, but
>>>>>>>now 1 ply deeper.
>>>>>>>
>>>>>>>Tony



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.