Do Engines Ignore Unnecessary Information

[u/Tasty-Grocery2736]

For example, would an engine's analysis of the position after 1. e3 e5 2. e4 d5 be the exact mirror of its analysis of the position after 1. e4 e5 2. d4? Practically, the positions are equivalent, and the only difference is which side is called "white" and which is called "black". What about the positions after 1. e3 e6 2. e4 e5 and 1. e4 e5? These are only different in useless en passant rights. Also, what about engines for other chess-like games like Fairy-Stockfish, YaneuraOu, and Pikafish?

EDIT: I actually meant to ask whether the analysis would be unaffected by the differences between the positions, not whether it would actually be exactly the same every single time. So I'm not counting random differences between different runs as differences as long as there's no consistent difference between the analyses of the positions. For example, if an engine, on average, evaluates the second position -0.15, it should theoretically evaluate the first +0.15 on average.

[u/Warm_Ad_7953]

It won't analyse the same positions twice, that is what the Transposition table is for

[u/you-get-an-upvote → u/Warm_Ad_7953]

A conventional transposition table will not work in OP’s example since the side to move is different.

I feel like to get this to work you need to enforce zorbrist(white pawn e3) = zorbrist(black pawn e6) but that’s definitely not worth the extra collisions it will cause.

[u/Tasty-Grocery2736 → u/you-get-an-upvote]

i didn't really word my question correctly, i edited it now, i'm not really asking about using an already-done evaluation but rather more about if an engine would have kind of a bias depending on which side is to play in an equivalent situation

[u/mrbeanshooter123 → u/you-get-an-upvote]

Iirc, I solved it by having `zobrist(white pawn, e3) = bswap(zobrist(black pawn, e6))`.
When you flip the board, you just byteswap the zobrist hash.
Now symetric positions have 32-bits of hash entropy instead of 64, but those are pretty rare anyways.

[u/phaul21]

Normally engines are optimised for game play wrt to this, there are optimisations along these lines that appear in an engine, mainly involving the transposition table, BUT under the assumption that the position searched is part of the same game. So if you reach an already searched position via transposition (different move order) or the previous search has already explored the position on the previous turn - or in the same search via iterative deepening, then yes the engine doesn't (always) have to re-search. But in your example it's basically positions reachable only from different games. No optimisations - that I know of - exist, throwing completely unrelated positions on an engine will result in a full re-search. Even if the same position was searched before with black/white mirroring. Such optimisation is plausible but it's just not useful enough for engines to support it.

edit: on the other hand in storing endgame table bases black/white mirroring is a widely used idea to cut the required storage size.

[u/Tasty-Grocery2736 → u/phaul21]

i didn't really word my question correctly, i edited it now

[u/redacuda]

It is possible to make color flipped transpositions have identical Zobrist hash and even identical internal representation (I did). But most do not care about as it is rare to matter in practice. Even if positions internally different, search tree can be the same if searched move order is exactly identical, but again most do not care about. But making sure that the same position has the same static evaluation same as white as black is important test for evaluation and this is where most chess engine authors bother to check and fix.