Using evaluation hash score as current bestscore (initial guess)

[xr_a_y]

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]

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.

[D Sceviour]

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]

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?

[D Sceviour]

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.

[xr_a_y]

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]

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.

[xr_a_y]

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]

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?

[xr_a_y]

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 ...