Puzzle with mate scores in TT

[Evert]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

[silentshark]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

[Evert]

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

Mate scores in the hash table are not problematic. Some ways of dealing with mate scores in the search can be problematic with certain ways of storing mate scores in the TT if you don't take care of what you're doing.
If the mate score returned from a position is always "this position is mate-in-N" (so it gets adjusted to "this position is mate-in-N+1" when backed up to the parent) and that's also what you store in the TT, there is no problem.

[micron]

Spandrel gives these results for Fine #70.

Code: Select all

...
38   3.04    165 kn  0.055 s     Kb1 
39   2.94    186 kn  0.062 s     Kb1 
40   2.94    198 kn  0.066 s     Kb1 

Your 40 ply search is _very_ small. 198K nodes total. Crafty searches about 10x that much.

Thanks for spotting a recently-introduced accounting bug!
QS nodes were not included. The correct value is 264 kn, which reduces the discrepancy somewhat.
Robert P.

[bob]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Again, the obvious question is "why?" Why would you exclude a perfectly valid score???

[bob]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

Mate scores are not problematic, if you do the simple score adjustment necessary to change the score from "mate-in-N-from-the-root" to "mate-in-N-from-current-position". It is a trivial bit of code. It can be significant when you use egtbs as those are mate scores that are more efficient when they come from the TT than from an EGTB probe, repeatedly.

[silentshark]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

Mate scores are not problematic, if you do the simple score adjustment necessary to change the score from "mate-in-N-from-the-root" to "mate-in-N-from-current-position". It is a trivial bit of code. It can be significant when you use egtbs as those are mate scores that are more efficient when they come from the TT than from an EGTB probe, repeatedly.

Ok, Evert/ Bob, I hear you. How about this, then? How likely are you to have problems if you don't look after mate scores (as outlined by Bob) in the TT?

[Dann Corbit]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

Mate scores are not problematic, if you do the simple score adjustment necessary to change the score from "mate-in-N-from-the-root" to "mate-in-N-from-current-position". It is a trivial bit of code. It can be significant when you use egtbs as those are mate scores that are more efficient when they come from the TT than from an EGTB probe, repeatedly.

Ok, Evert/ Bob, I hear you. How about this, then? How likely are you to have problems if you don't look after mate scores (as outlined by Bob) in the TT?

It is certain to cause problems because the distance to mate will be wrong if you don't track the distance.

[Evert]

Ok, Evert/ Bob, I hear you. How about this, then? How likely are you to have problems if you don't look after mate scores (as outlined by Bob) in the TT?

Depends on how you deal with mate scores.
When the recursive call returns a mate-in-N score, I adjust it to mate-in-N+1 before returning it. That's also the value that is stored in the TT and I don't need to do anything special to it when it's returned after a hash probe.

[bob]

one approach is to never store mate scores in the hash table. Is this such a bad deal?

Maybe not, they're probably rare enough that it doesn't affect playing strength too much, but to me it sounds as arbitrary as saying "I don't store captures in the transposition table".

no, it's different in that it avoids a problem. mate scores in the hash table are problematic, captures are not.

Mate scores are not problematic, if you do the simple score adjustment necessary to change the score from "mate-in-N-from-the-root" to "mate-in-N-from-current-position". It is a trivial bit of code. It can be significant when you use egtbs as those are mate scores that are more efficient when they come from the TT than from an EGTB probe, repeatedly.

Ok, Evert/ Bob, I hear you. How about this, then? How likely are you to have problems if you don't look after mate scores (as outlined by Bob) in the TT?

The most common problem is that you will announce a mate in N, Then on the next search you might announce mate in N+5. And the next move you see mate in N+11... Scores will bounce around and you might well end up drawing due to repetition or 50 moves when it was avoidable.

But the correction is trivial... so why not do it?