Author: Miguel A. Ballicora
Date: 09:35:15 02/13/02
Go up one level in this thread
On February 13, 2002 at 11:35:23, Robert Hyatt 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.
>
>How can that _not_ be accepted by the C standard? It is a pure fact of
>2's complement arithmetic. IE the range 0x8000 <= N <= 0x7FFF has been
>a classic 2's complement 16 bit value since 2's complement was first
>defined. Hardware _must_ do that right or the hardware can't do 2's
>complement at all. The compiler shouldn't care and I have never seen such
>a limit on the negative bound of a 2's complement number. For N bit words
>the range has always been -2^N <= X <= (2^N)-1...
It is guaranteed by the C standard that a 16 bit signed integer (it could be
short int, for instance) will have at least a valid range between -32767 and
32767. It does not guarantee that -32768 will be accepted. You are assuming that
the C standard sticks to the 2's complement arithmetic. It looks like it does
but in a certain range for portability reasons. A C compiler would work with a
1's complement processor just as fine if you stick to the standard.
An interesting corollary is that the portable range of a signed 1 bit integer in
a bitfield is only 0 and a value that you do not know what it is. You can test
that with bit != 0. In a 2's complement would be -1. But this is just a
curiosity.
Regards,
Miguel
>
>
>
>
>>
>>>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.