Author: Heiner Marxen
Date: 18:31:34 02/10/02
Go up one level in this thread
On February 10, 2002 at 19:49:01, Miguel A. Ballicora wrote:
>On February 10, 2002 at 19:28:33, Scott Gasch wrote:
>
>>You know reading this again I realize I misspoke and probably did more to
>>confuse you than to clarify. Let me try this again.
>>
>>When your search finds a mate it returns a score that is based upon that mate's
>>distance from the root of the search. So if you find a mate somewhere in your
>>search you will build the mate score based upon the distance from the root.
>>
>>When hashing such a score you can get yourself into trouble. Instead of hashing
>>the mate score as distance from root you want to hash it as distance from the
>>node you are hashing. For example, if you are at ply 5 and the recursive search
>>has returned a +mate in 12 ply score.
>>
>>If you simply store "mate in 12 ply" for this node's value you have trouble if
>>you come across the same position later at a different distance from the root.
>>Like you see it at ply 3, for example. Well then you lookup the hash table
>>value and its wrong -- it says this is a mate in 12 ply but its not anymore.
>>This time it's a mate in 10 ply from the root because you're 2 ply closer to the
>>root when you saw it.
>>
>>So hash the distance from the current position to the mate instead of the
>>distance from the root to the mate. To do this simple subtract ply from the
>>mate score. In our example we have mate in 12 ply and we first see it at ply 5.
>> Store as mate in 12 - 5 ply (mate in 7 ply) in the hash table.
>>
>>Then when you hit it later at ply 3, get the real score of the mate from the
>>root by adding in ply. So you lookup mate in 7 ply and add current distance
>>from root (3) to get "mate in 10 ply from the root".
>>
>>I hope I've been more clear this time. Good luck
>>
>>Scott
>
>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
Hey, that is interesting!
This is exactly the way I would do it, since it is so logical.
Everybody else seems to do it the other way round:
when creating a mate value, all the adjust_out() operations that would
be applied to it on the way back to the root, are applied immediately,
and around hash table access this is adjusted in the opposite direction.
And where you adjust in/out, nothing happens.
May be this method is a bit faster, but I'm not even sure about that.
Also, mate values as alpha or beta may raise problems, this way.
With your adjustment method there is no such problem :-)
BTW, I would probe/store the hash table _outside_ of the adjustments.
Logically they are associated with the makemove()/unmakemove().
Cheers,
Heiner
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.