Using evaluation hash score as current bestscore (initial guess)

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
xr_a_y
Posts: 543
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Using evaluation hash score as current bestscore (initial guess)

Post by xr_a_y » Thu Jun 06, 2019 8:04 pm

Most engine has a hash entry for static score, directly inside the main TT or in a separate table. This allows to not call eval.

But i also see that many top engines are using hash score as initial bestscore (under appropriate conditions). I get the point of having the best possible guess to take pruning decision but i dont understand how pruning margins can then be good for both classic static scores and for hash "search" score.

Why is this working? Why not using two types of margin depending on the initial static score: from evaluation or from search.

Here are xiphos condition

Code: Select all

  best_score = static_score;
  if (hash_data.raw && !pos->in_check)
  {
    if ((hash_bound == HASH_LOWER_BOUND && hash_score > static_score) ||
        (hash_bound == HASH_UPPER_BOUND && hash_score < static_score) ||
        (hash_bound == HASH_EXACT))
      best_score = hash_score;
  }

jorose
Posts: 232
Joined: Thu Jan 22, 2015 2:21 pm
Location: Zurich, Switzerland
Full name: Jonathan Rosenthal

Re: Using evaluation hash score as current bestscore (initial guess)

Post by jorose » Thu Jun 06, 2019 9:25 pm

If I read Xiphos code correctly then the bestscore there is just the current best score estimate for the purposes of things like futility pruning. The value gets reset before the move loop is reached.

In an ideal world the static score would be equivalent to the true outcome of the game. Instead we have some error term which we hope gets reduced by a higher depth search. Using the additional information we get from hash simply reduces this error term.
-Jonathan

D Sceviour
Posts: 419
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: Using evaluation hash score as current bestscore (initial guess)

Post by D Sceviour » Thu Jun 06, 2019 9:39 pm

It may be that we want a static evaluation to determine whether the position is improving. This is how various selective searches can make comparisons. The hash score is not effective to determine if the position is improving from the previous position since it represents a bound that may be higher or lower than the more accurate static evaluation. The hash score is only useful for beta cutoffs. Xiphos does handle this nicely.

Dann Corbit
Posts: 9662
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Using evaluation hash score as current bestscore (initial guess)

Post by Dann Corbit » Thu Jun 06, 2019 10:35 pm

You will often see a needed estimate for the score of a move.
If the move is already in the hash table, then that is used as the estimate.
If the move is not in the hash, then eval() is called to create an estimate.
Usually this is used for pruning decisions {typically in null move processing} rather than for alpha-beta window width estimates.

It seems that some experimentation might be useful here.
How about calling quiesce if the move under consideration returns an eval close to the current position's estimate?
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

D Sceviour
Posts: 419
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: Using evaluation hash score as current bestscore (initial guess)

Post by D Sceviour » Thu Jun 06, 2019 10:53 pm

Dann Corbit wrote:
Thu Jun 06, 2019 10:35 pm
You will often see a needed estimate for the score of a move.
If the move is already in the hash table, then that is used as the estimate.
If the move is not in the hash, then eval() is called to create an estimate.
Usually this is used for pruning decisions {typically in null move processing} rather than for alpha-beta window width estimates.

It seems that some experimentation might be useful here.
How about calling quiesce if the move under consideration returns an eval close to the current position's estimate?
You are not looking closely enough at the post. There are two (2) hash values stored - hash bound score and a static evaluation. The hash score is not used as an estimate.

User avatar
xr_a_y
Posts: 543
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Using evaluation hash score as current bestscore (initial guess)

Post by xr_a_y » Fri Jun 07, 2019 4:45 am

D Sceviour wrote:
Thu Jun 06, 2019 10:53 pm
Dann Corbit wrote:
Thu Jun 06, 2019 10:35 pm
You will often see a needed estimate for the score of a move.
If the move is already in the hash table, then that is used as the estimate.
If the move is not in the hash, then eval() is called to create an estimate.
Usually this is used for pruning decisions {typically in null move processing} rather than for alpha-beta window width estimates.

It seems that some experimentation might be useful here.
How about calling quiesce if the move under consideration returns an eval close to the current position's estimate?
You are not looking closely enough at the post. There are two (2) hash values stored - hash bound score and a static evaluation. The hash score is not used as an estimate.
Indeed, I understand well why and how those scores are used, I wonder how they can be used the same way, one being an eval score (probably on a board with hanging pieces !) and the other being a more correct search score. I don't get how the same pruning margins can be used with both ?

D Sceviour
Posts: 419
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: Using evaluation hash score as current bestscore (initial guess)

Post by D Sceviour » Fri Jun 07, 2019 12:54 pm

xr_a_y wrote:
Fri Jun 07, 2019 4:45 am
Indeed, I understand well why and how those scores are used, I wonder how they can be used the same way, one being an eval score (probably on a board with hanging pieces !) and the other being a more correct search score. I don't get how the same pruning margins can be used with both ?
It is not clear anymore if the original programmer understands either. Today, they get an idea and then test 10,000 games. If it improves elo then go on to the next idea. Brute force seems to be a modern programming method. In the posted example, Xiphos is trying to narrow the pruning window between the static evaluation and the bounded hash score.

User avatar
xr_a_y
Posts: 543
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Using evaluation hash score as current bestscore (initial guess)

Post by xr_a_y » Fri Jun 07, 2019 5:15 pm

Brute force seems to be a modern programming method.
But I want to understand what I'm doing in Minic.
I'd like to make use of this usefull information (the hash score), that is probably a better information than the static eval, but I don't think it is clear that the same margin shall be applied to both usage.

Probably smaller margin can be applied when using hash score and maybe pruning can be triggered at different depth.

For example, razoring based on static score is quite risky but based on hash score it seems quite safe to me.

jorose
Posts: 232
Joined: Thu Jan 22, 2015 2:21 pm
Location: Zurich, Switzerland
Full name: Jonathan Rosenthal

Re: Using evaluation hash score as current bestscore (initial guess)

Post by jorose » Fri Jun 07, 2019 5:23 pm

I think it is clear the adjusted value could technically utilize tighter bounds. How much tighter depends on the information gained from hash. On the other hand, a position found in your hash may be a more difficult one on average, so perhaps less tight bounds would be better after all.
Most likely these are things you could tune, but whether or not that is worth it I cannot tell you, I have not tried it myself.

Why not just try it in Minic?
-Jonathan

User avatar
xr_a_y
Posts: 543
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Using evaluation hash score as current bestscore (initial guess)

Post by xr_a_y » Fri Jun 07, 2019 6:44 pm

jorose wrote:
Fri Jun 07, 2019 5:23 pm
I think it is clear the adjusted value could technically utilize tighter bounds. How much tighter depends on the information gained from hash. On the other hand, a position found in your hash may be a more difficult one on average, so perhaps less tight bounds would be better after all.
Most likely these are things you could tune, but whether or not that is worth it I cannot tell you, I have not tried it myself.

Why not just try it in Minic?
I will ;-)

I'm busy tuning history score for move ordering for now ...

Post Reply