Author: Bas Hamstra
Date: 00:46:18 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.
>
>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
In my case I ignore this problem and I am not aware of any problems and simply
store MATE-Ply. My PV's practically always show a correct path to mate. Probably
less of a problem when you don't use an aspiration window at the root? How
serious is this problem anyway?
Best regards,
Bas.
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.