TTable & how to handle mate,stalemate,repetition values

[MattieShoes]

Wouldn't the draw scores you aren't storing propagate backwards to parent nodes and then get stored in the hash table?

[sje]

And in addition to the above, when the scores for a known draw/mate/lose position are stored in a transposition table, they should be marked "exact". They should also be given the largest possible draft as long as this doesn't adversely interfere with the transposition table entry overwrite replacement strategy.

[Don]

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.

You can check to see if the current move is a repetition, but your program cannot force repetition if you don't build repetition draws into the search.

[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.

You can check to see if the current move is a repetition, but your program cannot force repetition if you don't build repetition draws into the search.

I'm not sure I understand your point. Symbolic scores all draws with a zero, and it's the same zero each time for each draw. Position repetition is checked early at each node, before almost everything else. And the program has more than once forced a draw by repetition to save itself from a loss.

[sje]

Wouldn't the draw scores you aren't storing propagate backwards to parent nodes and then get stored in the hash table?

The minimax of the draw and the alternatives is the score that's passed up and potentially stored in the transposition table. It may or may not be zero depending on the window and the alternatives.

[Don]

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.

You can check to see if the current move is a repetition, but your program cannot force repetition if you don't build repetition draws into the search.

I'm not sure I understand your point. Symbolic scores all draws with a zero, and it's the same zero each time for each draw. Position repetition is checked early at each node, before almost everything else. And the program has more than once forced a draw by repetition to save itself from a loss.

I misread what you posted. I thought you said that you check for repetition before the search begins, but I see that you said you check before doing the probe.

You probably already know this and are just simplifying your statement, but you are not being 100% accurate to say that there are no path dependency problems even if you don't explicitly store a repetition draw in the table. Just the fact that a position can have a repetition in it introduces the GHI problem and many hash table scores (even if they are not scored as draws) can be dependent on a repetition draw.

In practice, this does not seem to be a huge problem. If the day ever came in which we solved the game of chess with a search, it would not constitute a proof until we have dealt with that.

[bob]

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.

This is not the problem. The problem is where the draw occurs somewhere _below_ the current node and the draw score gets backed up to the current node. Now you _do_ have a big problem...

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.

[bob]

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.

Only drawback is 50 move draws are just as problematic. And even worse are all the non-draw scores you store and then use later in a different path where the ultimate non-drawn position unfortunately passes through a 3-fold repetition or runs into the 50-move rule, which the program has no clue about...

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.

[hgm]

Wouldn't the draw scores you aren't storing propagate backwards to parent nodes and then get stored in the hash table?

Yes, they will, and this is a big problem. They also propagate in a non-obvious way: the fact that one move which would be normally best except that stupid play in the path leading to it can be reduced to draw, so that another move (with a lower score, but still better than draw) now becomes best. And that score would then go in the TT, and when you later find a more intelligent path to the same position it hits upon the corrupted entry which has a wrong score and a wrong best move.

In Joker one of the things I do to ameliorate the problem is to recognize repetitions, but in stead of scoring them, I back up the information to the root that the line went through a repetition. I pass this as a bitmap, where the bit corresponding to the tree level of the first occurrence of a repeated position is set. The rule for backing up is that a node backs up the bitmap of its best move. When A node finds out that the bitmap returned by a move has the bit corresponding to the current tree level set, meaning that it is now planning a PV that will repeat the current position, it tops off the score by a draw score. Such a draw score can safely go into the hash, as it is based on the path below the node, not the path leading to it.