TT & symmetry

[MahmoudUthman]

Has anyone tested hashing positions in a color agnostic way ?

[AlvaroBegue]

No. What would the point be? You won't encounter symmetric positions in a search tree often enough for this to be worth any complication.

[Evert]

Yes, I think Reinhard Scharnagl did that, and posted some results from it. I don't know how far his testing went, and sadly he isn't around anymore to comment on it.
In a practical sense, once you get away from opening positions, such positions would be sufficiently rare that it doesn't matter one way or the other.

[ZirconiumX]

Myself, Robert Taylor and Manik Charan debated trying this in our colour-agnostic engine Monochrome.

Manik raised the point of a colour-agnostic hash returning a false positive for repetition detection after a triangulation. Whether this would actually occur in the search tree is up for debate, but we decided to add a "colour" key (in so far as the engine only recognises of a position has been flipped or not).

[hgm]

Manik raised the point of a colour-agnostic hash returning a false positive for repetition detection after a triangulation.

You should not use the agnostic key for repetition detection, of course. Hashing and repetition detection are separate functions.

[Gerd Isenberg]

Has anyone tested hashing positions in a color agnostic way ?

I used it in a DirGolem approach in an experimental HansDamf some years ago. A quadbitboard plus ep and castling rights, and zobristkey were color flipped in make move to always generate moves for both sides in the same order (only white to move). The dependency zob[piece][sq] == bswap(zob[piece^1][sq^56]) seemed not to lead to significant more collisions as far as I remember. I did not elabortate on additional hits in symmetrical positions or did not try to probe with a byte swapped zobrist key. Reinhard Scharnagl also used color agnostic move generation but afaik not hashing.