SF search inconsistency

[Ralph Stoesser]

I don't understand what you mean. SF detect repetition by comparing position hash keys from the history stack of the current search line. Positions detected as draw by repetition will not end up in the TT. It would be an error to save positions detected as draw by repetition in the TT, because the draw score is not related to the position itself but to current search line only.

Draw scores detected in leaf nodes affect scores of parent-nodes, grand-parent nodes etc. and those get saved in TT. Those nodes get probed in some completely other line and provide false information. That is the problem, but there is no sane way to fix this without radically affecting performance of program.

OK, now I understand why you think that this problem is very likely the reason for the wrong draw scores in this queen endgame position. Thank you.

[Ralph Stoesser]

@Joona,
do you have tried to not save positions in TT for which the score depend on repetition draw detection? I also assume that would affect the program performance radically, but I would like to know exactly how radically the effect is. Therefore I have a test setup ready. But if you say it's not worth to try it, then I'll better do something more usefull (drink a beer or something ).

[mcostalba]

@Joona,
But if you say it's not worth to try it, then I'll better do something more usefull (drink a beer or something ).

To find something more useful then drinking a beer is very difficult...in the best case you can go to equal

[zamar]

@Joona,
do you have tried to not save positions in TT for which the score depend on repetition draw detection?

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

You'd need to hack search() to not only return a score but also an extra flag. I believe it's a waste of time, but I've been proven to be wrong many times

But if you say it's not worth to try it, then I'll better do something more usefull (drink a beer or something ).

How about taking a long walk instead? Very refreshing and you possibly get many good thoughts.

[Ralph Stoesser]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

[jwes]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

[bob]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

None of this solves the problem, however. You can store an entry that does not lead to a repetition, and look it up in a position where it would lead to one, since path information is not hashed...

[Ralph Stoesser]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

None of this solves the problem, however. You can store an entry that does not lead to a repetition, and look it up in a position where it would lead to one, since path information is not hashed...

But there would be at most a two-time repetition in the path. By rule this is not a draw. Therefore retrieving a non-draw value from TT should be OK.

[bob]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

None of this solves the problem, however. You can store an entry that does not lead to a repetition, and look it up in a position where it would lead to one, since path information is not hashed...

But there would be at most a two-time repetition in the path. By rule this is not a draw. Therefore retrieving a non-draw value from TT should be OK.

How can you tell whether it is 2 or 3? Hashing grafts things from A to B in the tree. And then that gets grafted somewhere else. It would be easy to get a score backed up that actually represents a search thru a repetition. And all you know is (sometimes) it is a repetition. Doesn't matter whether it is 2 or 3. If you miss a 2, the next hit can miss a 3.

There really is no solution to this except to include path information in the hash, which effectively kills hashing.

[Ralph Stoesser]

But how do you draw the line? For instance if there is node at depth = 5 which one grand-grand-grand-grand-child is repetition draw, do you still want to avoid saving value to TT?

Yes. It's the only correct way I guess.

How about a node where all of the (non-losing) children lead to draws by repetition?

None of this solves the problem, however. You can store an entry that does not lead to a repetition, and look it up in a position where it would lead to one, since path information is not hashed...

But there would be at most a two-time repetition in the path. By rule this is not a draw. Therefore retrieving a non-draw value from TT should be OK.

How can you tell whether it is 2 or 3? Hashing grafts things from A to B in the tree. And then that gets grafted somewhere else. It would be easy to get a score backed up that actually represents a search thru a repetition. And all you know is (sometimes) it is a repetition. Doesn't matter whether it is 2 or 3. If you miss a 2, the next hit can miss a 3.

There really is no solution to this except to include path information in the hash, which effectively kills hashing.

My trial to avoid retrieving wrong draw scores from TT alone killed the program performance. Theoretically it would be possible to avoid missing 3-fold repetitions, but that would kill performance even more. So it's a zombie approach anyway.

But regarding this problem I find it interesting that TT works in general, even in positions where repetitions are very likely.