Stockfish tablebases and hash collisions question

[Uri Blass]

I remember that in the past people increased the probability for hash collision and it was one of the changes that gave elo for stockfish.

I wonder if this change help or is counter productive in analyzing tablebases positions.

I also wonder if hash collisions can cause stockfish to
have mistakes like showing mate that is shorter than the shortest mate or even show mate score in a drawn position.

[Eelco de Groot]

I remember that in the past people increased the probability for hash collision and it was one of the changes that gave elo for stockfish.

I wonder if this change help or is counter productive in analyzing tablebases positions.

I also wonder if hash collisions can cause stockfish to
have mistakes like showing mate that is shorter than the shortest mate or even show mate score in a drawn position.

I can only speak for myself here that I don't remember anyone bringing this up before so maybe it is good that you do Uri. I suppose because Stockfish stores the result of a tablebase probe it is also possible that you get collisions. You could not store the probe result to counteract this but I'm not sure if it is possible that you get a tablebase "miss" if you don't find the result in hash. I don't know enough about that.

In PV nodes you don't return a hash hit, I think avoiding collisions is one possible rationale for this (just one of many). I remember that Uly in Rybka forum or OpenChess forum wanted to have the possibility to return from deep TThits in PV nodes because that makes it better for forward-backward analyzing. I highly suspect this is stil in the PA-GTB version (from Jeremy Bernstein) but I don't know how you could do without it. There is of course a potential issue in regular Stockfish that in PV nodes you still immediately return if a move other than the PV move fails high above beta-1 (nullwindow search >= beta, not above alpha but beta, there is a difference here because PV node) This null window search can fail high for numerous non safe reasons, but we accept that because it fails high above (>=) beta assuming this will in most cases get resolved by new searches with a higher alpa beta window if it travels down to the Root, and if not, another move is chosen by the opponent. Probably true but if the result of a null window search is Mate and this Mate is unproven (or wrong) does this still work, i.e aspiration search will finally resolve this when beta is higher than the false Matescore? Seems a bit tricky to assume that that always works.

[Rodolfo Leoni]

Just as a note, Jeremy Bernstein didn't consider a TB hit a valuable entry. At least, not for his PHs system. About Uri's question..... I've absolutely no idea!

[syzygy]

I remember that in the past people increased the probability for hash collision and it was one of the changes that gave elo for stockfish.

It was not the increased number of hash errors that gave Elo, but the increased number of hashed position held in the same amount of memory.

I wonder if this change help or is counter productive in analyzing tablebases positions.

If the position is in the tablebase, the analysis is basically finished before you start it.

If you mean endgame position (not in the tablebases), then it will depend on how important the increased number of hash entries is. In a Fine #70-type position you don't need many hash entries and a hashing error might be really annoying.

I also wonder if hash collisions can cause stockfish to
have mistakes like showing mate that is shorter than the shortest mate or even show mate score in a drawn position.

That should certainly be possible. If somewhere along the PV the only drawing move leads to a position incorrectly stored as a quick mate, the search will accept a losing move that leads to a slower death than the fake mate.