Author: Miguel A. Ballicora
Date: 08:24:22 07/09/01
Go up one level in this thread
On July 08, 2001 at 12:29:55, Bruce Moreland wrote:
>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.
Now I understand why I did not understand the theoretical reason not to store
exact mate values in the hash table. It is because apparently I am not doing the
adjusting in the traditional way. I did not know what the traditional way was.
What I do is:
at the end of search(), rather than:
return best;
I do something like this:
if (is_mate_value(best))
return best-1;
else
return best;
So, the value is adjusting when it comes back from the leaves. In this way,
the values do not depend on the distance to root, depend on the distance
to leaves, which is correct. I can come back to this position any time, pick the
value from the table and the value is always meaningful. Mate in 5 will be
always mate in five no matter how I reach this position. Any comments on this?
Is it right? any drawbacks?
In theory, I should not have problems with storing exact values but I am not
100% sure. Extensions make this value not perfectly correct since I can find
a mate in 8 with checks faster than a mate in 5 with silent moves.
Maybe that is the reason why I see oscilations in the evaluation when I am
detecting mates. May be I should store bounds like >= MATE in 8, or maybe
I should do Bruce's approach and forget about all this. I agree with Bruce, when
a Mate is found the most important thing is not to have bugs. The game is
decided generally at this point... as long as there is no bug.
All I can say is that I haven't seen serious problems so far with the way I do
it. When a mate is found is eventually delivered.
Regards,
Miguel
>
>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.