Re: Draw scores in TT
Posted: Sat Apr 14, 2018 7:41 pm
thx for the info and links.
--
Srdja
--
Srdja
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.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.
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 wrote: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.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.
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 wrote: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 wrote: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.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.