Two fold or three fold repetition?

[Sven]

First time or second time when position with bishop on f2 was encountered (after e5e4 or Tb1 ) two fold repetition condition was not valid and that value had been stored in the TTable.

Checking for repetition draw before probing TT is actually required ...

[Henk]

First time or second time when position with bishop on f2 was encountered (after e5e4 or Tb1 ) two fold repetition condition was not valid and that value had been stored in the TTable.

Checking for repetition draw before probing TT is actually required ...

Rb1 is not yet a draw and I think position with Rb1 was stored in TT. (It is a draw after Bf2 has been played) So it played Rb1 which is a blunder. Checking for repetition draw before probing TT did not help in this case. Instead it should have recognized that entry of Rb1 in TT is outdated and can not be used.

Or maybe before returning Rb1 from TTable check if opponent can force a draw after Rb1.

Btw what a bad site has this become. I had to restart my browser to update this post.

[Sven]

Counting the first repetition of a position belonging to the current search tree as a draw must work. If it does not work in your engine then you should find the bug and fix it. From your description it seems that you also include repetitions of positions above the root, i.e. from the game history. But those require two repetitions to count them as a draw.

[Henk]

Yes this is about game history and TTable. When arrived at a position p it sees child node of position p is only once in game history. So it assumes no draw and stores p in TTable. But two moves later it looks up position p in TTable and returns it. But it does not see position p leads to a draw now because two moves were added to game history making child node a draw.

[Sven]

Once again: before looking up a position in TT, check for repetition ...

[Henk]

Once again: before looking up a position in TT, check for repetition ...

My code checks if move in transposition table causes a draw. But it does not look deeper.
It does not check if best move of child position may cause a draw.

[Sven]

It does not matter whether you look up the current position or a child position. It matters in which order you take your decision. Deciding that the score of a position shall be the one taken from TT should not be done without prior checking for path-dependent conditions (repetition and usually also 50-moves counter) since these conditions are not known in TT.

[Henk]

It does not matter whether you look up the current position or a child position. It matters in which order you take your decision. Deciding that the score of a position shall be the one taken from TT should not be done without prior checking for path-dependent conditions (repetition and usually also 50-moves counter) since these conditions are not known in TT.

Easiest way is to do two fold and not three fold repetion in game history. Or add length of game history to current depth to see if entry is out of date.
This length should also be added to entry in ttable of course when storing it.

Some Fifty move rule bugs still to go.

[Sven]

It is certainly a bit easier to always return a draw score when repeating a position for the first time, regardless whether the repeated position (the original) belongs to the search tree or to the earlier game. But then you accept a small inaccuracy if the repeated position (and the move that was played there) belongs to the earlier game and the moving side actually has a better option than the one that allowed the opponent to go into repetition. The same situation within the search tree is different since there you can assume that a possible better option would be found by the search so one repetition would be enough reason to return a draw score.

Not sure what you mean by "length of game history to current depth" ... but nevertheless, you should refrain from storing any path information in the TT, that can have a negative impact on usability of your TT. In other words: you won't solve the problem you described above by storing more information in the TT, instead you should solve it by only using the TT after having checked for a repetition (which you can't derive from TT).

[Henk]

I mean len = number of moves played from start of the game or last capture, castling etc.

If there was a repetition draw possible than many entries in TT poluted for they used the wrong value for that position when calculating their value.
Same holds for best move stored in these entries being the wrong best move.

I mean one wrong value may infect the whole tree.