Author: Miguel A. Ballicora
Date: 14:42:53 02/12/02
Go up one level in this thread
On February 12, 2002 at 16:16:54, Dan Newman wrote:
>On February 12, 2002 at 10:55:09, Miguel A. Ballicora wrote:
>
>>On February 11, 2002 at 19:21:18, Ralf Elvsén wrote:
>>
>>>On February 10, 2002 at 19:49:01, Miguel A. Ballicora wrote:
>>>
>>>>I never understood what the people is doing with the mate values, I always
>>>>get confused. I am glad that I came up with my own approach before I asked or
>>>>saw any post about it. :-)
>>>>
>>>>What I do in pseudo code in Gaviota is
>>>>
>>>>search (alpha, beta)
>>>>{
>>>> adjust_in (&alpha, &beta); /* increments alpha += 1 and beta += 1 if they
>>>> are positive mate values, do the opposite if
>>>> it is a negative mate value */
>>>> probe_hashtables_normally()
>>>>
>>>> loop { /* normal alpha beta stuff */
>>>> makemove();
>>>> value = search_moves_for_best_value(-beta, -alpha);
>>>> unmakemove();
>>>> best = keep the best value;
>>>> }
>>>>
>>>> store_in_hashtables_normally();
>>>>
>>>> adjust_out(&best); /* decrement best -= 1 if it is a +mate value
>>>> increment +=1 if it is a -mate value */
>>>> return best;
>>>>
>>>>}
>>>>
>>>>And basically, I do not do anything else. I store in the hashtables without
>>>>any change. adjust_out() it is used too when I return early.
>>>>
>>>>Regards,
>>>>Miguel
>>>
>>>Here's another one who is doing the same thing :) It is really
>>>simple and clear. My functions are called "upstep" and "downstep" :)
>>>
>>>Ralf
>>
>>Good! Then I am not crazy. At least I am not alone in the nuthouse. :-)
>>
>>Regards,
>>Miguel
>
>I tried something like this in Shrike last year, but ran into trouble.
>The idea I had was to have the mate-in-n scores at a node really mean
>mate-in-n from that node. Then, I thought, I could just store the
>scores without adjustment in the hash table. (And it made more
>sense to me as well.)
>
>I also realized that alpha and beta mate-in-n scores needed to be
>adjusted too. That is (I think) where I had the trouble. I ended
>up with bound scores that were oustide the [-32768,+32767] range
BTW, I think is a bad idea to allow -32768. That is not a valid 16 bit value
accepted by the C standard and it might work on some implementations and not in
others. That number can give you some headaches with some operations.
It is much safer to use a portable range -32767, +32767.
>that is allowable in my program. This caused my hash table
>entries to become corrupted (since I stuff the score into half
>a 32-bit word by first adding 32768 to it and then ORing the
>result in). The out-of-range error happens because a mate-in-n
>bound can end up being incremented more than n times.
>
>Anyway, I gave up and put things back the way they were. After
>seeing that others have done this successfully I think I'll have
>to try it again...
>
>-Dan.
At the beginning of search I do exactly
alpha = adjust_in(alpha);
beta = adjust_in(beta);
where the declaration is exactly:
static eval_t
adjust_in (eval_t x)
{
if (MATE100_VALUE < x && x < MATE_VALUE)
return x + 1;
if (-MATE_VALUE < x && x < -MATE100_VALUE)
return x - 1;
return x;
}
The value cannot be adjusted if it is MATE_VALUE.
Nowhere in my program I allowed a value that is supposed to be a score
to be out of range. I have ASSERT() everywhere checking this.
I think that this should be enough. adjust_out() is just a simmetric function
and as I said, every time I return I use that. That's all.
Regards,
Miguel
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.