In the currently running D9 tourney, Weini lost a game against GopherCheck in an even position playing a very very stupid move. The game was quite ok (https://lichess.org/iCoTzK5u) but in this position
[d] 4k3/1R6/6p1/Bp3p1p/4pP1P/4P3/b5PK/1r6 w - - 8 51
Weini played Rxb5??.
Can it be a "real" hash collision where the full zhash are equal AND the move is playable ?
Of course I cannot reproduce the issue. On this position, Weini is playing b7b8+ at all depth (I stop searching at depth 23, with a draw score).
I also suspect something about 3 reps draws but I don't know why it would happen specificaly in this game and not others ...
Can it be a "real" hash collision
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 931
- Joined: Tue Mar 09, 2010 3:46 pm
- Location: New York
- Full name: Álvaro Begué (RuyDos)
Re: Can it be a "real" hash collision
That looks like a bug. Something I used to do in my engine Ruy-López is clearing up the search state (hash, killers, history-heuristic tables...) after every move, so I could reproduce everything it did exactly (except for maybe time control). It may make you lose ~30 Elo, but it will let you find bugs potentially worth 100s of Elo.
-
- Posts: 160
- Joined: Sat Jan 28, 2017 1:29 pm
- Location: The Netherlands
Re: Can it be a "real" hash collision
If you use a 64 bit hashkey (and verify it), a real has collision is very very rare I think. My engine for instance does not verify if the tt move is actually playable, I just assume that it is.
-
- Posts: 2495
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: Can it be a "real" hash collision
I had a strange occasional bug where stalemate detection and pruning could collide, and that lead to losses exactly like this one here.
The basic flow was like this:
* try very stupid move
* find that it was so stupid that everything below it would be pruned away
* at the end of the for-loop over the moves, see that no move has been tried
* examine "not in check"
* conclude it's a stalemate
* return draw score
In your case, this perhaps might happen in negamax.cpp if "validMoveFound" doesn't get set because everything is pruned. That could also depend on TT contents so it could be hard to nail down.
My solution was to also count legal, but pruned moves and only enter the checkmate/stalemate logic if both the counts for tried AND pruned legal moves were 0.
The basic flow was like this:
* try very stupid move
* find that it was so stupid that everything below it would be pruned away
* at the end of the for-loop over the moves, see that no move has been tried
* examine "not in check"
* conclude it's a stalemate
* return draw score
In your case, this perhaps might happen in negamax.cpp if "validMoveFound" doesn't get set because everything is pruned. That could also depend on TT contents so it could be hard to nail down.
My solution was to also count legal, but pruned moves and only enter the checkmate/stalemate logic if both the counts for tried AND pruned legal moves were 0.
Rasmus Althoff
https://www.ct800.net
https://www.ct800.net
-
- Posts: 160
- Joined: Tue Jan 23, 2018 10:18 am
- Location: Rotterdam
- Full name: Ronald Friederich
Re: Can it be a "real" hash collision
I had the same problem a few months ago with Rofchade while changing my searchroot routine, the reason why could be different in your engine however...
In Rofchade I noticed after a while that the strange moves happened after the search reached panic time and the search had to be aborted. If that happens all search info created after the last fully searched move must be ignored, because that info is invalid. I thought I did that correctly but there was one point I had forgotten to exclude the info. So as soon as the search is stopped due to reaching panic time (or other cases, for instance when multi threading) nothing must be written to the hashtable etc., or you could end up with very strange info in it.
In Rofchade I noticed after a while that the strange moves happened after the search reached panic time and the search had to be aborted. If that happens all search info created after the last fully searched move must be ignored, because that info is invalid. I thought I did that correctly but there was one point I had forgotten to exclude the info. So as soon as the search is stopped due to reaching panic time (or other cases, for instance when multi threading) nothing must be written to the hashtable etc., or you could end up with very strange info in it.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Can it be a "real" hash collision
Thank you all. I now have some ideas for this bug hunting.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Can it be a "real" hash collision
I do that also (resetting everything), but I use random initialization for my zobrish key (that is fairly stupid ...), I am going to use a permanent seed for that soon !AlvaroBegue wrote: ↑Wed Sep 12, 2018 9:43 pm That looks like a bug. Something I used to do in my engine Ruy-López is clearing up the search state (hash, killers, history-heuristic tables...) after every move, so I could reproduce everything it did exactly (except for maybe time control). It may make you lose ~30 Elo, but it will let you find bugs potentially worth 100s of Elo.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Can it be a "real" hash collision
Yes the hash are verified, 64 bits, and the TT is verified also (is valid). So you are right, this is probably not a hash issue.sandermvdb wrote: ↑Wed Sep 12, 2018 9:50 pm If you use a 64 bit hashkey (and verify it), a real has collision is very very rare I think. My engine for instance does not verify if the tt move is actually playable, I just assume that it is.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Can it be a "real" hash collision
In Weini pvs search, pruning is done only if a validMoveFound has already been set. So if it is still false at the end of the loop, there was indeed no valid moves.Ras wrote: ↑Wed Sep 12, 2018 10:00 pm In your case, this perhaps might happen in negamax.cpp if "validMoveFound" doesn't get set because everything is pruned. That could also depend on TT contents so it could be hard to nail down.
My solution was to also count legal, but pruned moves and only enter the checkmate/stalemate logic if both the counts for tried AND pruned legal moves were 0.
But i'll check that twice ... thanks
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Can it be a "real" hash collision
Indeed, nothing is added to TT is stopFlag is set. But recently we discuss in the forum that it is maybe worth using the partially searched root move.Ronald wrote: ↑Wed Sep 12, 2018 10:05 pm I had the same problem a few months ago with Rofchade while changing my searchroot routine, the reason why could be different in your engine however...
In Rofchade I noticed after a while that the strange moves happened after the search reached panic time and the search had to be aborted. If that happens all search info created after the last fully searched move must be ignored, because that info is invalid. I thought I did that correctly but there was one point I had forgotten to exclude the info. So as soon as the search is stopped due to reaching panic time (or other cases, for instance when multi threading) nothing must be written to the hashtable etc., or you could end up with very strange info in it.