End game flag in zobrist key

[stevemulligan]

If an eval function uses the end game flag to determine the score, do I need to account for this flag in the zobrist key?

The reason I ask is I found in fixed depth testing I get scores from the hash table that are not necessarily from the current end game state.

In self play my version with the hash table gets about -70 Elo and this is the only oddity I've been able to find so far.

[hgm]

Well, I am pretty sure it can never be the reason for the -70 Elo.

[stevemulligan]

Ahh, I should have been able to answer that myself. I forced the end_game flag to 0 and I still see the big Elo drop in self play.

I'm perplexed. To try and isolate this bug all I do is store the full eval score in the cache. All the other TT features are disabled. So all I'm doing is caching the results of an eval based on Zob key..

And this is still causing a big difference in fixed depth testing and I would expect the Elo difference to be 0. (It is 0 when I play with the same features enabled)

[hgm]

Well, one test would be to check if the retrieved eval is equal to a freshly calculated eval, in all cases.

But if you don't use the TT for doing something useful (like pruning branches that were already searched, or using the TT move in move sorting), a big table could easily slow you down a factor >2, explaining the 70-Elo drop.

[syzygy]

I'm perplexed. To try and isolate this bug all I do is store the full eval score in the cache. All the other TT features are disabled. So all I'm doing is caching the results of an eval based on Zob key..

Are searches returning the same evaluation at the same depth in the same number of nodes? (Probably not, unless the slow down mentioned by the previous poster is the explanation.)

[Daniel Shawul]

If you determine the end game flag from material score, then there is no need to incorporate it in zobrist hash key. Game phase is a derived feature not something fundamental like enpassant square that needs to be included in the key itself. What do you use to determine game phase ?

[lucasart]

If an eval function uses the end game flag to determine the score, do I need to account for this flag in the zobrist key?

The reason I ask is I found in fixed depth testing I get scores from the hash table that are not necessarily from the current end game state.

In self play my version with the hash table gets about -70 Elo and this is the only oddity I've been able to find so far.

The key is a signature of the position. So if you hash the position into it, I don't see any reason to hash an "endgame flag" into it: the endgame flag is already a function of the position!
I don't know what your "endgame flag" is exactly, but I must warn you:
* make sure it's not path dependant !! Adding a condition like the move count since the begining of the game, is a stupid idea...
* what do you do with an endgame flag in the eval anyway ? I'm worried your eval will suffer discontinous behaviour that way. It's better to calculate an opening and and endgame score, and interpolate linearly between the two. That's what everyone does since Fruit showcased this concept.

[stevemulligan]

* what do you do with an endgame flag in the eval anyway ? I'm worried your eval will suffer discontinous behaviour that way. It's better to calculate an opening and and endgame score, and interpolate linearly between the two. That's what everyone does since Fruit showcased this concept.

Ahh! I was trying to keep 1 score and I would set the end_game flag at the start of each search by counting # of pieces. That is a much easier way of doing it.

Also, thank you to Ron & HGM, comparing the cached score to the real eval helped track down a couple problems. I'm still stuck on something strange but I have the entire day to track it down