Why are you reducing the problem to the level of "assumptions"? The problem I described above is a real game-playing problem, and it can also occur when playing another engine that has the same "always score first repetition as draw" behaviour. I think that "assumptions" do not always help in being precise enough.tpetzke wrote:Yes, I agree. I gave both positions to my engine and iCE scored them also as draws.
The underlying assumption is that if my opponent plays in a position 34. Qf8 once (which enables a DRAW by repetition) he will do so also a 2nd time because he obviously does not realize this will become a draw.
For engines this assumption works pretty well. Humans are less predictable.
Thomas...
Regarding the fix I described above, I forgot to mention another detail that is required for the fix to work. The condition to stop the repetition detection loop is slightly more complex. Actually there should be two loops:
a) a first loop starting at "current ply - 4" and going backwards in steps of 2 plies up to the root node of the current search (but not beyond), stopping at the first repetition (pos.hashKey == currentPos.hashKey) and always scoring that as a draw,
b) a second loop that is only started if the first loop did not encounter a repetition, starting 2 plies backwards from the node that was last visited by the first loop, going backwards in steps of 2 plies up to the beginning of the game, stopping at the first repetition (pos.hashKey == currentPos.hashKey), and only scoring that as a draw if it is the second repetition.
EDIT: of course both loops can stop when crossing the boundary given by the last irreversible move.
For the last part of b) it would be necessary to store the information whether game positions were already repeated, e.g. as a "numberOfRepetitions" once per position (or once per game position if these are kept separately, depending on individual data structures). With this information the second loop would score a repetition as draw if the repeated position (which is a game position above the search root) has "numberOfRepetitions > 0" so that we now have at least the second repetition.
Of course it is also possible, and may be even simpler, not to store the number of repetitions but instead to continue the second loop after the first repetition and to only stop at the second one.
Also it may be possible that there is some clever solution to combine both loops in one, although I would not recommend that.
Does that sound reasonable? I think we already discussed that detail a couple of months ago but I don't recall whether we found this type of solution back then.
Sven
Spoken like a true programmer.
