## Draw scores in TT

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
smatovic
Posts: 1610
Joined: Wed Mar 10, 2010 9:18 pm
Location: Hamburg, Germany
Full name: Srdja Matovic
Contact:

### Re: Draw scores in TT

thx for the info and links.

--
Srdja

jwes
Posts: 778
Joined: Sat Jul 01, 2006 5:11 am

### Re: Draw scores in TT

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.

syzygy
Posts: 4818
Joined: Tue Feb 28, 2012 10:56 pm

### Re: Draw scores in TT

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

jwes
Posts: 778
Joined: Sat Jul 01, 2006 5:11 am

### Re: Draw scores in TT

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.

syzygy
Posts: 4818
Joined: Tue Feb 28, 2012 10:56 pm

### Re: Draw scores in TT

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

Uri Blass
Posts: 8828
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

### Re: Draw scores in TT

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