My program can't mate KQK or KRK!

[Evert]

Problem for me was zobrist hash keys didnt account for positions repeating (ie, for 3-fold repitiion). As a result, engine would do strange things and weird moves, not realizing that these things would lead to draws. Fixing this fixed the problem entirely.

I don't understand how that works. Are you probing the transposition table before checking for repetitions? I don't see why else you'd have a problem there...

[DrRibosome]

Problem for me was zobrist hash keys didnt account for positions repeating (ie, for 3-fold repitiion). As a result, engine would do strange things and weird moves, not realizing that these things would lead to draws. Fixing this fixed the problem entirely.

I don't understand how that works. Are you probing the transposition table before checking for repetitions?

You're right, that was the problem. Instead, now, I simply encode the number of times the position appeared (up to 3) in the hash key, and there is no need to probe.

I only mentioned this because I had the exact same symptoms as the original poster and it seemed reasonable that an edge case bug like it might have slipped into his program.

[Chan Rasjid]

Hello,

Problem for me was zobrist hash keys didnt account for positions repeating (ie, for 3-fold repitiion). As a result, engine would do strange things and weird moves, not realizing that these things would lead to draws. Fixing this fixed the problem entirely.

I don't understand how that works. Are you probing the transposition table before checking for repetitions?

You're right, that was the problem. Instead, now, I simply encode the number of times the position appeared (up to 3) in the hash key, and there is no need to probe.

I only mentioned this because I had the exact same symptoms as the original poster and it seemed reasonable that an edge case bug like it might have slipped into his program.

I am not sure I understand what you mean by "encode the number of times the position appeared (up to 3) in the hash key".

Nearly all of us do encode castling and ep rights info into our zobrist hash key that is used to probe our transposition table - numbers or random numbers that represent the king/queen side castling per color and ep target squares. We XOR these with the hash key.

You seem to indicate you have something like:
hashkey ^= randon_number_1repetition;
... 2/3 repetition etc. If it is, this is new to us. It may not be necessary. We all have codes after makemove() that checks that the new node does not repeat any nodes prior in the move history leading up to this new node. We update a stack of hashkeys and we scan backwards in the history stack to see if the new hashkey repeats any in the stack - this would discover node repetition.

Or have I miss something?

Best Regards,
Rasjid.

[hgm]

I can't say I understand it either. When my search encounters a position it has already seen before, it terminates that branch with a win, draw or loss score (depending on what the rules specify for repetitions). There never is any search of the position. So there also would not be anything to store in the hash table for a "two-times-visited position". All positions in the hash table are automatically first-visited positions. There is no need to encode that in the hash key anymore than that there is need to have a Zobrist key for "white has not resigned yet".

Even if your engine only scores 3rd repetition a draw, there should be no need to distinguish first and second repetitions. They are logically equivalent. Either you can force a win from that position, or you can't. If tou can, that shuld work from a repeated position exactly the same as a new one.

[Evert]

You're right, that was the problem. Instead, now, I simply encode the number of times the position appeared (up to 3) in the hash key, and there is no need to probe.

I still don't understand.

What I do is test for repetition before probing the transposition table and if I find a repetition I return a draw score immediately. I suppose that if this causes the parent move to become "best" the draw score will enter the transposition table, which may not be correct, but I don't see how your scheme would remedy that...