# Computer Chess Club Archives

## Messages

### Subject: Re: The Code for the Rybka-Mate-Bug

Author: Ronald de Man

Date: 05:16:57 12/18/05

Go up one level in this thread

```On December 16, 2005 at 00:11:28, Robert Hyatt wrote:

>On December 14, 2005 at 19:25:38, Dann Corbit wrote:
>
>>On December 14, 2005 at 19:18:28, Uri Blass wrote:
>>
>>>On December 14, 2005 at 18:53:21, Dann Corbit wrote:
>>>
>>>>What's the other way to do it?
>>>
>>>see my post in
>>>
>>>http://www.talkchess.com/forums/1/message.html?470096
>>
>>Can't the same position (therefore) have a huge number of different scores then
>>(depending on where we saw it in the tree)?
>>
>>Tbis way seems more complicated to me.
>
>
>It is.  The obvious solution is when you store a mate score, it must be mate in
>N from the current position depth, not the root, not from the start of the game.
> Otherwise you will get _really_ confusing mate scores from hash.

Indeed. For a moment I liked this other way, but Dann's observation is correct.
I don't see how one can make it work correctly. Think of a mate position that
can be reached from the root in 5 plies, but can still be delayed for 4 more
plies. Then it's a forced mate in 9 plies (mate in 5), but the search might
report 5 plies (mate in 3). You can also have the opposite case: a mate position
that is first found by the search (and stored in hash) at the end of a long
series of checks, but can actually be reached in far fewer plies. In this case
the search would report a number of moves to mate that is too high.

I don't see how this could be solved by storing the mate score as an upper or
lower bound instead of an exact score. There's no guarantee to have either an
upper bound or a lower bound, as far as I can see.

Storing the number of plies to mate counted from the start position indeed
solves the problem of aging hash entries, but it creates problems as well.

```