TalkChess.com

thx for the info and links.

--
Srdja

smatovic wrote:How do you handle draw scores by repetition and fifty move rule in TT?

I use zero as draw score, and simply prevent to load such an value from TT,
i guess there are better techniques to prevent an mix up with an eval score of zero.

--
Srdja

edit: assuming i wish to use an 16 bit signed integer as tt score with centi pawn based eval.

One thing that has not been mentioned is that a repetition means either that the position (or at least the subtree) is very drawish or one side or the other has made a mistake. The simple solution is to not store the value in the TT and return 0.

jwes wrote:

smatovic wrote:How do you handle draw scores by repetition and fifty move rule in TT?

I use zero as draw score, and simply prevent to load such an value from TT,
i guess there are better techniques to prevent an mix up with an eval score of zero.

--
Srdja

edit: assuming i wish to use an 16 bit signed integer as tt score with centi pawn based eval.

One thing that has not been mentioned is that a repetition means either that the position (or at least the subtree) is very drawish or one side or the other has made a mistake. The simple solution is to not store the value in the TT and return 0.

I don't think many engines store a value in the TT if the current position repeats an earlier position (the repetition is detected before the TT is probed). But not storing the draw value in the TT does not solve the problem. The draw value is backed up to the parent node and stored there, and even if draw values are never stored, those path-dependent draw scores will make many other scores path dependent. There is no solution to this, unless you just don't store scores in the TT at all (but only moves), or you eliminate transpositions by hashing into the key the path from root to node (really bad).

syzygy wrote:

jwes wrote:

smatovic wrote:How do you handle draw scores by repetition and fifty move rule in TT?

I use zero as draw score, and simply prevent to load such an value from TT,
i guess there are better techniques to prevent an mix up with an eval score of zero.

--
Srdja

edit: assuming i wish to use an 16 bit signed integer as tt score with centi pawn based eval.

One thing that has not been mentioned is that a repetition means either that the position (or at least the subtree) is very drawish or one side or the other has made a mistake. The simple solution is to not store the value in the TT and return 0.

I don't think many engines store a value in the TT if the current position repeats an earlier position (the repetition is detected before the TT is probed). But not storing the draw value in the TT does not solve the problem. The draw value is backed up to the parent node and stored there, and even if draw values are never stored, those path-dependent draw scores will make many other scores path dependent. There is no solution to this, unless you just don't store scores in the TT at all (but only moves), or you eliminate transpositions by hashing into the key the path from root to node (really bad).

That is the point of the remark about mistakes. It means that the score from a repetition quickly tends to not contribute to the scores of nodes above.

I'm not really sure what this has to do with mistakes.

The question is if there are positions that engines never find the best move because of the problem of not encoding the history of the position into the hashkey.

I think that it may be interesting what is the best way to deal with cases when history is clearly more relevant.

For example suppose you add a rule that you can win in chess also by visiting all the squares of the board by one of your pieces(it means for example that KN vs K may be sometimes a win for the side with the knight but not always because it may be a draw by the 50 move rule if the knight did not visit enough squares before the endgame happened so it needs more than 50 moves to visit the rest of the squares).