TTable & how to handle mate,stalemate,repetition values

[Desperado]

Hi,

maybe a very simple question, but it isabsolutley confusing me.

I am using a fail-hard framework.(just beside).

I am not sure how to handle mate values, or repetition values
in my transposition table. In some situations there are some incorrect mate announcements. (ex: mate in 5 instead of 2...when retrieving).
(especially on the next search(not iteration),or when analyzing and
move and remove...)

So i just switched of storing mates to trans and looked what happend.
Then somehow a similar thing with repetition, but how to know if a
parent-node gets a repetition draw,and that this value is not a "evaluation score".(nothing to switch off in this case )....

so finally my question, is there a standard way to handle things like this ?

i have had a look at cpw-engine(nice) , and there before storing any
values to trans, of course the tt_flg is set, but flags arent set for mate values ?! (any reasons? and the typically handling of checking the bound-
like alpha>=beta -> alpha=beta, also isnt done for mate scores?!)

I would be happy if someone could give me a short instruction to this.

[Sven]

It is preferrable not to store a draw by repetition in the hash table since detecting a repetition includes path information which is usually not available in the hash table.

Regarding mate scores, a popular choice is to transform them from "absolute" to "relative" when storing them, and vice versa when retrieving:

Code: Select all

int toRelativeMateScore(int score, int height) {
    assert(abs(score) > +MAX_EVAL);
    return (score > +MAX_EVAL) ? score + height : score - height;
}

int toAbsoluteMateScore(int score, int height) {
    assert(abs(score) > +MAX_EVAL);
    return (score > +MAX_EVAL) ? score - height : score + height;
}

That way, mate scores stored in the hash table become independent from the point in the tree where they are found, they only carry "distance to mate" information.

It may be an option to change the alpha/beta bounds by the same offset (height) when retrieving a mate score from the hash table and deciding about a cutoff, but I'm not perfectly sure how it should be done correctly.

Sven

[bob]

Hi,

maybe a very simple question, but it isabsolutley confusing me.

I am using a fail-hard framework.(just beside).

I am not sure how to handle mate values, or repetition values
in my transposition table. In some situations there are some incorrect mate announcements. (ex: mate in 5 instead of 2...when retrieving).
(especially on the next search(not iteration),or when analyzing and
move and remove...)

So i just switched of storing mates to trans and looked what happend.
Then somehow a similar thing with repetition, but how to know if a
parent-node gets a repetition draw,and that this value is not a "evaluation score".(nothing to switch off in this case )....

so finally my question, is there a standard way to handle things like this ?

i have had a look at cpw-engine(nice) , and there before storing any
values to trans, of course the tt_flg is set, but flags arent set for mate values ?! (any reasons? and the typically handling of checking the bound-
like alpha>=beta -> alpha=beta, also isnt done for mate scores?!)

I would be happy if someone could give me a short instruction to this.

Let's take the two cases separately (mate and draw).

Mates are straightforward. A mate score for most of us is "distance from the root", in the form score = MATE - ply, so deeper mates get smaller scores so you prefer the shorter mate. But inside the search, you are not at the root, you are somewhere below the root.

Suppose you are searching 10 plies deep and you have found a mate in 5 moves. Which will give you a score of MATE-10 since at ply 10 you found that side was mated. Suppose you want to store a score at ply=5. What you store is MATE-5, _not_ MATE-10, because the mate is 5 plies away from the current position, where it is still 10 away from the root. Now whenever you retrieve this score from the hash table, you always have to again subtract the current ply to correct it. For example, suppose you later find this hash entry again at ply=5. The score says MATE-5, but you subtract the current ply from this (5) to make it mate in 10 because that converts it back from "mate in N moves from this node to mate in N moves from the root."

That's pretty simple.

Draws are a different thing and there is little you can do about them. Some won't store draw scores in the hash table. The problem is that draws are based (for the most part, excepting insufficient material draws) on something in the move path, such as repetitions, or the 50-move rule counter. But those are not factored into the hash signature. Don't store them and you lose a lot of efficiency. Do store them and you get some inaccuracy. ANd even if you don't store them, any hash table score is improper anyway, because the score is based on the position and not the path. There are lots of ways to reach the same position, some passing through a 3-fold repetition and some not. So you have a problem with draws no matter what you do. I just ignore it. I do clear hash scores (but not best moves) as I get close to the 50 move rule draw limit to give Crafty a chance to do something to reset the counter rather than getting everything from the hash table...

[bob]

It is preferrable not to store a draw by repetition in the hash table since detecting a repetition includes path information which is usually not available in the hash table.

Regarding mate scores, a popular choice is to transform them from "absolute" to "relative" when storing them, and vice versa when retrieving:

Code: Select all

int toRelativeMateScore(int score, int height) {
    assert(abs(score) > +MAX_EVAL);
    return (score > +MAX_EVAL) ? score + height : score - height;
}

int toAbsoluteMateScore(int score, int height) {
    assert(abs(score) > +MAX_EVAL);
    return (score > +MAX_EVAL) ? score - height : score + height;
}

That way, mate scores stored in the hash table become independent from the point in the tree where they are found, they only carry "distance to mate" information.

It may be an option to change the alpha/beta bounds by the same offset (height) when retrieving a mate score from the hash table and deciding about a cutoff, but I'm not perfectly sure how it should be done correctly.

Sven

Since mate bounds are relative, I adjust them the same way, and "unadjust them" before testing for a cutoff...

[MattieShoes]

A less than optimal solution is to store in the hash but not use hash pruning on nodes with a mate or draw score. I figured I wanted the nodes in the hash for move ordering purposes but I couldn't figure out the issue with mate scores (I realize now I wasn't un-adjusting them) so it stores them but always calculates out the mate at each ply. Generally only takes a fraction of a second since the move ordering is there. I think I may go fix the mate score thing now so I can hash prune mate scores!

[Desperado]

ok! thx for replies, well explained

[jwes]

It is preferrable not to store a draw by repetition in the hash table since detecting a repetition includes path information which is usually not available in the hash table.

It seems pointless at best to store a draw by repetition in the hash table as nearly always there is the same position searched to a deeper depth, and if something has overwritten it, it will be overwritten again anyway when the search comes back to this position.

[bob]

It is preferrable not to store a draw by repetition in the hash table since detecting a repetition includes path information which is usually not available in the hash table.

It seems pointless at best to store a draw by repetition in the hash table as nearly always there is the same position searched to a deeper depth, and if something has overwritten it, it will be overwritten again anyway when the search comes back to this position.

The problem is, inside the search all we have is a draw score. No way to tell what kind of draw it was. But in any case, draw by repetition and draw by 50 move rule both suffer from identical problems.

And non-draw positions suffer from the _same_ problem as well.

[Don]

A good solution for draws is to have a unique repetition score that is not used for normal scoring. For instance you could make all scores an even number except for repetition draws which could be any odd number. Then you simply do not store odd scores in the hash table.

If odd scores are repetition draws, then you must have an odd contempt factor. The contempt could be 1 or -1 for instance.

You can use a score of zero though for other draws. There is no law against having different draw scores for different kinds of draws.

Hi,

maybe a very simple question, but it isabsolutley confusing me.

I am using a fail-hard framework.(just beside).

I am not sure how to handle mate values, or repetition values
in my transposition table. In some situations there are some incorrect mate announcements. (ex: mate in 5 instead of 2...when retrieving).
(especially on the next search(not iteration),or when analyzing and
move and remove...)

So i just switched of storing mates to trans and looked what happend.
Then somehow a similar thing with repetition, but how to know if a
parent-node gets a repetition draw,and that this value is not a "evaluation score".(nothing to switch off in this case )....

so finally my question, is there a standard way to handle things like this ?

i have had a look at cpw-engine(nice) , and there before storing any
values to trans, of course the tt_flg is set, but flags arent set for mate values ?! (any reasons? and the typically handling of checking the bound-
like alpha>=beta -> alpha=beta, also isnt done for mate scores?!)

I would be happy if someone could give me a short instruction to this.

[sje]

For three draw kinds [fifty-moves insufficient repetition], Symbolic quickly checks for these conditions prior to a transposition table probe, so there's no sense with storing any of them in the transposition table. Therefore, no draw path dependency problems.

For stalemates, these are stored in the transposition table. But these scores are path independent.

Mate (and lose) scores are stored in the transposition table with values from MateIn1 down to MateIn4096 and LoseIn0 (checkmated) up to LoseIn4095. These too are path independent.