Author: Miguel A. Ballicora
Date: 22:27:29 02/12/02
Go up one level in this thread
On February 12, 2002 at 21:47:01, Dan Newman wrote:
>On February 12, 2002 at 17:42:53, Miguel A. Ballicora wrote:
>
>>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.
>>
>
>Actually, my MIN_SCORE is -32767 (for symmetry), but my program doesn't
>break until the score goes below -32768--at least on the PC. I guess
>that other processors could use something other than twos-complement,
Ok, I undestand. Anyway, it is not your case but I will complete the idea.
-32768 might break in any processor, even in twos complements. For instance,
suppose that you use 16 bits and you have
i = -32768;
when you try to do x = -i; x will not be what you expect, I will still be
-32768. In a chess program is quite likely that a score will be negated. Of
course you might be using 32 bits, but as soon as you try to store that as 16
bits you might have a problem. Maybe not, but it is asking for a bug at one
point if one is not vigilant. Best is to avoid, as you do, the possitility of
having a score of -32768 at all.
>though I haven't heard of anything like that recently... I think perhaps
>some early computers used ones-complement, or sign magnitude. (In fact
>I heard a rumor of a ternary machine (Russian I think) years ago...)
>
>>>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
>
>Thanks, I'll have to try that sometime. I think I didn't try this before
>because at the time it seemed like a mistake to me to clip the bounds in
>that fashion, but I guess it makes sense since nothing's better than mate...
Let me know if you have a problem. It might alert me of something I did not
think of.
Regards,
>
>-Dan.
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.