Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Question to Dr. Hyatt and Bruce Moreland

Author: Bruce Moreland

Date: 09:29:55 07/08/01

Go up one level in this thread


On July 08, 2001 at 08:56:32, Alvaro Jose Povoa Cardoso wrote:

>
>My problems with mate scores adjustments are all gone now, thanks to the help of
>Dr. Hyatt and Bruce Moreland.
>
>In main.c of Crafty 16.18 there is the following notes:
>* A very interesting bug was found in storing mate bounds in the hash *
>* table, one I had not heard of before.  I now store two MATE         *
>* bounds, either > MATE-300, or < -MATE+300, which is conservative    *
>* but safe.
>
>Could you please explain why should we do so?
>
>
>Also this code is from Craft 18.XX
>  if (type == EXACT) {
>    if (value > MATE-300) value=value+ply-1;
>    else if (value < -MATE+300) value=value-ply+1;
>    if ((int) tree->pv[ply].pathl >= ply)
>      word1l|=tree->pv[ply].path[ply];
>  }
>  else if (type == LOWER) {
>    word1l|=tree->current_move[ply];
>    value=Min(value,MATE-300);  <--------|
>  }                                      |
>  else {                                 |
>    value=Max(value,-MATE+300); <--------|
>  }                                      |
>                                         v
>Could you also please explain the lines:
>	value=Min(value,MATE-300);
>	value=Max(value,-MATE+300);
>It was the inclusion of these two lines that solve all of my hash
>inconsistencies and mate scores problems in the hash table.
>But I don't understand how these two lines work, could you please explain?
>
>I also would apreciate very much an explanation from Bruce Moreland.
>I don't kow much about him but seams to me he is quite an expert on the field.
>
>
>Best regards,
>Alvaro Cardoso

I contend that during the part of the game where a mate score is not an instant
cutoff either way, I don't care about saving a few nodes, and I'd rather avoid
bugs.

The traditional way to score mates is you evaluate them as some function of
MATE_SCORE - "distance from root of search".  The problem with this is that if
you store that exact value in the table, when you find this later on you might
be at a different distance from the root.  So these scores need to be
manipulated in order to avoid this problem.  There ends up being code in the
hash table probe and more code in the hash table store.

I got sick and tired of screwing around with stupid bugs and complication, so I
just threw all the code away.

When my hash table store routine sees something that's either a mate score or a
bound that looks like it has something to do with a mate score, it turns it into
a bound that indicates "at least the longest possible mate" or "at most the
longest possible forced loss".  There are a few "gotchas" when you are failing
low on a mate score, or failing high on a loss score, but these can be handled
without too much trouble.

Once I figured out the possible cases I haven't had to spend any time worrying
about whether I got it right.

bruce




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.